Kickoff SproutCore Meetup Tonight!

If you are in the SF Bay Area and haven’t yet heard about tonight’s kickoff meetup, then check it out at http://javascript.meetup.com/6/ and let us know if you are coming.

Here’s what will will be up to:
7:00 - Meet and greet, get name tags and drinks
7:15 - pizza, pizza, and pizza (feel free to get another drink, too)
7:30 - Welcome from Charles
7:35 - View DEMO apps built for SproutCore site and announce winner
7:50 - Building SproutCore apps for NOKIA phones
8:05 - Hooking up SproutCore apps to the servers
8:20 - Q&A, mix and mingle

*****During the mix and mingle section, if you have code that you have questions about, Charles will be standing by to help you work through it, so bring your code with you.******

SproutCore 0.9.14 - “Github is Fun” Edition

SproutCore 0.9.14 was just released today with lots of bugs fixes and minor feature enhancements contributed by you and one really big new feature from me.  

Introducing Easy Install Frameworks

The SproutCore build tools have always had support for frameworks - basically libraries of JavaScript code that you can install and share between your applications.  In fact, both SproutCore and Prototype are included as frameworks.  When you do a build, you will see their output included with your own project.  

Installing and sharing frameworks has never been easy, however, until now.  0.9.14 includes three new utilities: sc-install, sc-update, and sc-remove.  These utilities will download and install, update or remove SproutCore frameworks from your project using Github.  It’s really easy.  For example, let’s say you wanted to get the latest bleeding-edge version of SproutCore installed in your project.  Just do the following:

cd MY_PROJECT_NAME
sc-install sproutcore

That’s it.  You should now find the latest version of SproutCore installed in a new frameworks directory.  If you want to later update it, just do:
sc-update sproutcore
Getting the latest SproutCore is one thing, but what about sharing frameworks of your own?  Well, this is easy to thanks to the power of Github.  Just open a github account and upload your framework (the contents of the folder you would put into the frameworks directory) as a new project.  The project name should begin with “sproutcore-YOUR_FRAMEWORK_NAME”.  For example, if you had created a sproutcore-enabled plotkit, you might name it sproutcore-plotkit.

Once you have this project available via git, you are all done!  Just tell anyone to go to their project and do:

sc-install YOUR_GITHUB_USERNAME-YOUR_FRAMEWORK_NAME

For example, if your Github username were “johndoe” and your project was called sproutcore-plotkit, then someone might install:

sc-install johndoe-plotkit

This will install the framework in their directory and they can get right to work using it.  sc-update will also work to let everyone receive your updates.

To use these tools, you will need to have Git installed.  There are installers available for every platform.  Easy install frameworks are just one new feature we have planned to deliver with our friends at Github, so getting this tool on your computer is a good idea for the future as well.

Updated Documentation

Also notable for this release, Onitunes has done some great work updating our JSDoc utility to run the latest version (version 2.0), which also improves the docs quite a bit.  Check out the docs on your machine or head on over to the hosted version to check them out.

Thanks

Finally, a special thank you to everyone who has contributed to this release.  This version has fixes and small feature enhancements submitted by more people than ever before.  Special congratulations to mguymon, YoNoSoyTu, Maurits Lamers, Gareth, Juan, and gskluzacek who had their first fixes applied.  Also a thank you to pbergtr, jdickens, chuck, Erich, and Andy who also have more features and fixes.

Full details of this release are below.

Release Details

 

Build Tools

 

  • The long form of sc-build -e is not –environment. It was misspelled.  (Thanks zoowar)
  • Fixed README for new apps to use the correct sc-build command.  (Thanks Spencer Ho!) 
  • Added sc-install, sc-update, and sc-remove.  These utilities work with github to automatically install and update plugin JavaScript libraries.
  • [FIX] Removed warning about NO_BODY_METHOD
  • Upgraded to a newer version of JSDoc that can provide a much more accurate description of the inline documentation for SproutCore.
  • sc_super() now works automatically and does not require you to pass this.
  • sc-server now autodetects Merb.root.  This means that you can start sc-server from any directory inside of your project and it will do the right thing.

 

Framework

 

  • Fixed bug in SC.SourceListView that could incorrectly hide groups. Closes #57. (Thanks mguymon)
  • Fixed bug in SC.ObjectController that would sometimes not commit all pending changes because the model object would clear the changes hash.  Also a test for this was added.  Closes #66.  (Thanks YoNoSoyTu!)
  • default index.html now has text/javascript added to script tags. Closes #71
  • server.js now handles namespaced prefixes. Closes #74
  • label_view now defaults to the span tag.  Closes #75.  (Thanks Erich!)
  • Added support for posting data in both URL-encoded and JSON formats via SC.server.  This makes for a much cleaner round-trip.  To use this, set the postFormat: property to SC.JSON_FORMAT in SC.server.  Closes #49. (Thanks Mauris Lamers!)
  • The newRecord property is now set to false once a record has been successfully sent back to the server.  A new internal property tracks when you are waiting on a record to be created on the server and refuses to submit it a second time. Closes #81 (Thanks Gareth!)
  • All internal calls for arguments.callee.base.apply() have now been switched to sc_super().  This means you MUST use version 0.9.13 or later of the build tools to work with the javascript.
  • Fixed a memory leak in IE that was caused by a self-reference to document. (Thanks Juan)
  • Improved documentation for a variety of classes. (Thanks gskluzacek)
  • SC.Server can now handled nested Server prefixes in case you have multi-level namespaces.

 

 

 

 

 

Writing SproutCore Apps with a Rails Backend

Lawrence Pit has written a great tutorial on building a SproutCore application and hooking it to a Rails backend.  This is by far one of the most common requests for new SproutCore developers and I’m really glad Lawrence has taken the time to share his knowledge.  Thanks Lawrence!

Read Sproutcore + Rails

PS.  Lawrence mentions that SproutCore’s built-in REST API is not well developed and he is generally right.  The current Server class in SproutCore was written before ActiveResource, GData or many other solid REST implementations were around.  It will be updated before SproutCore 1.0 but the current version will work just great as long as you adopt the semi-REST SproutCore model as Lawrence describes.  

 

SproutCore Mailing List Crosses 800

The SproutCore mailing list crossed 800 members yesterday.  Pretty impressive considering that just over a month ago fewer than 50 people were on the list.  The mailing list is growing quickly everyday as are the number of interesting cool apps people are building with the framework.

Which reminds me: the first SproutCore Demo Competition is coming to a close in just three days.  The purpose of this competition is to give you a place to show off what you achieved in just a couple weeks with SproutCore.  This is just a demo contest and everyone is new to SproutCore so no demo is too simple to show.  Let us see your work!  

I’ll review the code of at least the first 10 entries and provide feedback so you can get some help from the experts on how make your SproutCore app really shine. 

Link up your entry on the wiki page.

 

Firebug Gets Some Love

John Resign announced today that he and a few others will be taking over the Firebug project for Mozilla.  This is hugely important as the folks working on Firefox appeared to actively break Firebug with every beta release. 

It’s pretty clear that as software running in the browser becomes more complicated, the developer tools supported by each browser will become one of the most important features of that browser (at least to developers).  The browser vendors that don’t get that are going to really harm their position in the marketplace.

Way to go John.  We’re cheering you on!

Should Progressive Enhancements Be Required for a Web Application?

If you are building a client-side application in the web browser, what should happen when you turn the programming language off?  This is the issue raised by Steve Webster today.

A lot of people argue that the web is about accessibility and therefore a well designed, standards-compliant web page should practice progressive enhancement.  That is, if JavaScript is shut off, people should still be able to access the page.

I totally agree with this statement.  It is particularly true if you are a company like Yahoo, writing an ad-supported content-driven website where reaching the broadest audience possible is of the utmost importance.  Where is the business value is setting a high bar of entry for readers?

This is not the case however for thick-client web applications like SproutCore apps.  In this case, your users come to your site to use a fast, right, desktop-class application.  JavaScript is the key enabling technology behind the very features your users want to use.  Asking them to turn it on in their web browser only makes sense.

That said, there are a lot of progressive techniques that do still make sense.  Smoothly degrading your CSS for example is an obvious choice.  Also expensive things like animations that make the experience less pleasurable on slower browsers would be obvious places to cut back.  If you do use Flash (maybe for audio or video playback) that’s another good place to avoid requirements; asking users to enable an option built in to their web browser is way different from asking them to download and install a plugin.

If you want to support users with no JavaScript as well, build a reduced functionality site using traditional page-driven models that you can redirect your users to via a <noscript> and <meta> tag in your SproutCore app.

If you’re building a content site like the NY Times or Yahoo’s front page, make sure your page works even with JavaScript turned off.  It’s the best way to bring in the broadest audience.  If you are building a web app however, requiring JavaScript to be turned on so you can deliver a fast, fluid experience on the web will attract more customers because it will set you apart from the competition.

OpenSocial and SproutCore

Johannes posted a great tutorial about how to use SproutCore to create a social application using Google’s OpenSocial. It is worth a read.

http://blog.springenwerk.com/2008/07/socialsprout-using-sproutcore-in.html

A Day at the Forum

Danny Brewer created a SproutCore forum today. You can check it out at:

http://sproutcoredev.com/

I don’t know if anyone of us will be hanging out there but the more conversation the better!

Thanks Danny

SproutCore 0.9.13 - “Baker’s Dozen” Release (was SproutCore 0.9.12)

UPDATE: A late breaking bug in 0.9.12 was discovered this morning that prevented sc-build from functioning properly. It was fixed in a new release, 0.9.13.  Everything below is the same for 0.9.13, just with an extra bug fix.

SproutCore 0.9.12 release just rolled with some fabulous bug fixes and new features.  Here are the highlights:

 

  • Finally, Windows Goes Final.  The last two SproutCore gems have included experimental support for using the build tools on Windows.  Experimental as in, did not work.  In 0.9.12 the build tools are officially supported, as in, they finally work.  At least on my Windows machine.
  • Better Proxy Support.  0.9.11 included the debut of a new built-in proxy support which makes it uber-easy to test SproutCore with your favorite backend service.  There were a few bugs however, with both posts and query parameters.  These have both been fixed now.  The proxy also handles both cookies and redirects better.
  • sc_super().  SproutCore has always had built-in support for “calling super” in  your JavaScript.  The only problem was that to call your super’s method, you had  to use an elaborate string “arguments.callee.base.apply…”.  Now thanks to the build tools, you can call super with a nice shorthand:  sc_super().  This is replaced at build time on the server so if you are debugging, you will still see the old-style call in your code.
  • Combining Stylesheets & JavaScript in Dev Mode.  In development mode, the build tools normally server your CSS and JavaScript as individual files.  This makes it easier to debug and its faster for the page to reload.  In some browsers, however, (notably IE), having more than 31 CSS files can break it.  To solve this, you can use some new config options to have the build tools combine either your Stylesheets or JavaScript in development mode.  You can also use this new option to turn minification on or off in production or dev modes. See the release notes below for more info.  
  • OpenSocial.  Some folks are building SproutCore applications that work with OpenSocial, which is a really cool idea.  This release adds a useful feature allowing you to @import stylesheets instead of using link tags if needed.  If you are building an OpenSocial app or need this feature for some other reason, ask on the mailing list and someone it will be happy to help you out.
  • Bug Fixes!  A variety of bug fixes contributed by lots of different people.  Full details are below.

Special thanks and congratulations to august, onitunes, maloninc, schwa32, juan, and Johannes Fahrenkrug who all had patches included in this release.

To get the update, just do:

sudo gem update sproutcore

SproutCore Build Tools 0.9.12 Release Notes

 

Build Tools

 

  • Added :include_method = :link|:import option to the stylesheets_for_client helper.  This allows you to select between inclusion using link tags vs @import (which is required for OpenSocial apps) - Thanks Johannes Fahrenkrug!
  • Proxy now handles posts and rewrites Location headers so they stay in the same domain.  Should make this feature far more robust.
  • Proxy now handles query parameters. 
  • Build tools now replace all occurrences of “sc_super()” with a call to arguments.callee.base.apply().  This way you don’t have to remember the crazy-ass string to call super. (Thanks onitunes)
  • You can now start sc-server down inside of a project and it will find the proper level to work at.
  • Finally fixed all remaining known issues with using tools in Windows.  Works for me in my install.
  • sc-config.rb is now named sc-config.  The old name will still work.
  • sc-config now supports three extra options in the all config:
    • :minify_javascript :: name one or more modes that you want the JavaScript to be minified in.  Normally JS is minified in production mode, but you can use this to turn that behavior off if necessary for debugging.
    • :combine_javascript :: name one or more modes that you want JavaScripts to be combined in.  Normally JS is combined in production mode, but you can turn this on or off for mode as needed for debugging.
    • :combine_stylesheets :: name one or more modes that you want stylesheets to be combined in.  Normally CSS is combined in both production and development modes, but you can turn this on or off as needed.
  • [FIX] Build tools were not appending a timestamp to resource URLs like they should in order to gaurantee clean caching. 

 

 

Framework

 

  • SC.ButtonView & SC.MenuItemView now removes and adds the ‘active’ class name on mouseExited and mouseEntered when the mouse is pressed to provide better indication of whether an action will occur on mouse up. (Thanks schwa23)
  • SC.Record#toString now shows record type in description.
  • [FIX] SC.Timer now computes the next fire time before it executes your callback action.  This should avoid the situation where a timer would call your action, which would then take it past the last time it should fire and hence the last fire would never happen. (Thanks August)
  • [FIX] SC.Record#matchCondition() did not behave correctly when comparing record instances.  Fix by onitunes includes both a faster comparison method along with correct behavior + kickin’ unit tests
  • [FIX] some settings on the inline editor for multi-line edits were wrong.  Now fixed thanks to maloninc (#38)