SproutCore makes it to WWDC

Great News Everyone! I found out while searching the WWDC list that SproutCore will be at WWDC in June.
Here is what they say about SproutCore on the site:

“SproutCore is an open source, platform-independent, Cocoa-inspired JavaScript framework for creating web applications that look and feel like Desktop applications. Learn how to combine SproutCore with HTML5’s standard offline data storage technologies to deliver a first-class user experience and exceptional performance in your web application.”

Here is the full listing of sessions that will be at WWDC this year - http://developer.apple.com/wwdc/sessions/#session=1160

Looks like SproutCore is on the rise.

SproutCore Featured at SF Javascript Meetup

I just found out that Charles is speaking tonight in San Francisco at the SF Javascript Meetup group. He is going to be presenting SproutCore to a packed house of about 100 people.
You can read more details here - http://javascript.meetup.com/4/calendar/7519957/

Also, Douglas Crockford (they guy who literally wrote the book on JavaScript) is presenting after Charles. Let’s hope that SproutCore doesn’t steal his thunder.

So, Good Luck Charles. Make us proud.

Changes to SC.LabelView API

One of the oldest classes in SproutCore is the SC.LabelView.  This class simply displays strings of text (and optionally allows you to edit them with an inline editor).  Since I’m normalizing the SC API right now, this class is one of those that is simply too out of lockstep to maintain 100% compatibility in.  So I’m going to break the API.  I think you will see though that the new changes are well worth it.  Here is what you need to do to update your code:

The Old Way

In the past, to set the value of an SC.LabelView you set the content property.  For example, you might do something like this:


SC.LabelView.create({
  contentBinding: 'Contacts.detailController.fullName'
});

or if you were using the view helper:


<%= label_view :full_name, :bind => { :content => 'Contacts.detailController.fullName' } %>

If you wanted to set the content to a more complex object such as a record and extract a single value from it, you would use the property property to name the property key you wanted to check:


SC.LabelView.create({
   contentBinding: 'Contacts.contactsController.selection',
   property: 'fullName'
});

Or if you were using the view helper:


<%= label_view :full_name,
  :bind => { :content => 'Contacts.contactsController.selection' },
  :property => 'fullName' %>

The New Way

Now SC.LabelView follows the same convention used by all other views that include SC.Control (such as SC.ButtonView, etc.).  If you want to set the value of the label view, use the label property.  The example above becomes:


SC.LabelView.create({
  valueBinding: 'Contacts.detailController.fullName'
});

or with a view helper:


<%= label_view :full_name, :bind => { :value => 'Contacts.detailController.fullName' } %>

If you need to bind to a more complex object such as a record and you want to get a specific property, use the content property and set the name of the property key you want the label view to display using the contentValueKey:


SC.LabelView.create({
  contentBinding: 'Contacts.contactsController.selection',
  contentValueKey: 'fullName'
});

or with the view helper:


<%= label_view :full_name,
  :bind => { :content => 'Contacts.contactsController.selection' },
  :content_value_key => 'fullName' %>

That’s it.  Note that to use the :content_value_key in the helper above, you will need the new build tools.  If you are still using the old build tools, do the following instead:


<%= label_view :full_name,
  :bind => { :content => 'Contacts.contactsController.selection' },
  :properties => { :content_value_key => 'fullName' } %>

This change should basically bring you up to speed with the latest API.  Note that because of this shift, SC.LabelView can now be used as an item view in a collection.  The newly introduced SC.TextCellView has been merged into SC.LabelView and no longer exists as its own class.

 

The Road to SproutCore 1.0

I started work on SproutCore almost two years ago with the goal of making it easy to create speedy, rich, fluid applications on the web.   We’ve had to really push the boundaries of what is possible in the web browser to deliver something suitable but I’m happy to say that we are almost there.  SproutCore will go 1.0 this summer.

What does 1.0 mean?

SproutCore’s goal is to make it easy to build rich, fluid applications on the web.  We’ll go 1.0 when this objective has been achieved.  That means:

 

  1. Stable APIs.  These APIs will drive the framework for a long life ahead.
  2. Models, Views, and Controllers.  A full stack framework for not only managing widgets in your app, but managing the state.
  3. Automated Build Tools.  Generating performance optimized JavaScript and HTML is no easy task.  That’s why we’ve created this set of build tools.  
  4. Documentation, Testing, Tutorials.  Plenty of resources to ease you into development.  Building web apps is a whole new world, and we need lots of materials to explain how to do it.

 

What Has Been Done?

A lot of changes have taken place already with SproutCore that you may not yet know about.  Here are some of the more important ones:

 

  1. Google Code.  We are moving the SproutCore SVN repository to Google Code.  The new project is at http://sproutcore.googlecode.com.  Of course, most people will never need to visit this site since SproutCore is now also distributed through the Ruby Gems system.  The Google Code site will also be the location for all new tickets.  I have migrated over all open tickets to this system already.  Please file new issues there from now on. 
  2. New Website.  sproutcore.com is not going away.  Instead it is becoming the home to a new website geared towards helping developers using SproutCore to build applications.  Where the Google Code site will be your home if you are hacking SproutCore itself, if you are building an app using SproutCore, then sproutcore.com has much more to offer.  This blog is located there, as well as documentation, sample code, demos, and links to the Google Group and other items that you need.
  3. New Build Tools.  The new build tools, now hosted in the Google Code SVN is one of the biggest improvements I’ve made to SproutCore recently.  Not only are they faster and more consistent, but they make it brain dead easy to build fast loading web applications in a flash.  There are entire books written about how to optimize the packaging and loading of resources on your web page, but with these build tools you don’t need any of them because it does it all for you, all the while making it far easier to manage your own code as you work.

 

What’s Left To Do?

SproutCore has been evolving considerably over the last few months but mostly under the covers.  I’ve intentionally held off on some of the more visible changes to avoid disrupting people who are already using the framework.  In the next few months, though, you’re going to see some of the visible changes start to happen.  Here is what I currently have planned (it’s a lot):

 

  1. Full set of widgets.  SproutCore has a smattering of views right now to largely cover most of the common GUI controls you might need to build.  Expect to see a few new widgets come into the fold before launch as well as a major cleanup of the APIs to make them more consistent across the board.  I’m also going to update some of these APIs to encourage more use of controllers and less subclassing of views.
  2. Atom-REST Interface.  Server interaction is a bit like underwear, it seems to be very personal to everyone.  Most people end up writing their own server code, but I still want to provide an approach that makes it easy to interact with a service that requires less code.  The current system is designed to work with a psuedo-REST oriented API that doesn’t exist anywhere in the wild.  The new system will instead work with APIs built using a REST model, with an Atom-based file format or a JSON derivative of Atom.  Unlike the current code, this system will work with existing APIs used by GData.
  3. General API cleanup.  I’m going to scrub the API for SproutCore one more time before launch.  Expect some major and minor changes here to make everything most consistent overall.
  4. IE Support.  During the course of making some of these recent major changes, I’ve allowed IE support to lapse.  This will be resolved for both IE6, IE7, and IE8 by the time we launch.  I am also working towards building some tests that will make it easier to keep this code working.

 

As always, appreciate your feedback on this.  Find me on the Google Group, IRC (#sproutcore, freenode.net) or on this site.  Also, if you are interested in helping to hack at any part of the framework, please get involved!  If there are things missing from my list that you think should be there for 1.0, you can help out there to.  Hacking SproutCore on the Google Code site will tell you what you need to know to get started.