Moving to Git

I’ve been meaning to post this for awhile but I kept putting it off until I could put together more docs. Well, the docs still aren’t all done, but we’ve moved so here goes: SproutCore is moving to Git. Aside from the fact that all the cool kids are using Git these days, the primary reason for moving to Git is to make it easier for you developers to make your own copies of SproutCore and modify it yourself.

Trim methods; make changes; import SproutCore into your own project..and of course submit changes back to the root project. Git makes all of this much easier.

You can find information on how to get SproutCore from Git on the Hacking Page.

You can also find our new Ticketing System at Lighthouse.

New Feature: Property Chaining

I’ve just committed the latest changes to SproutCore to support property chaining.  This is an important change the SC API that could impact your code, though most likely only for the better.

The Old World

set() has always returned the value that you set of an object.  Since it was intended to replace the “=” in JS, this makes sense.  Just like you could do:

foo.bar = foo2.bar = c

You could do:

foo.set('bar', foo2.set('bar', c)) ;

The problem, of course, is that this model of setting values is not terribly useful.  In my informal survey, in fact, it appeared that almost no one actually uses it.

The New World

Enter the new world of chainable commands.  jQuery has gained a large following thanks mostly to its nifty chainability syntax.  Most methods return the object you just called a method on so you can chain commands like this:

$('.foo').show().css('color','red');

And all elements with CSS class ‘foo’ will be made visible and their color set to red.  Nice.  

This is a very useful way of writing JavaScript and we’re all about efficiency so SproutCore is moving towards a general pattern whereby methods that otherwise would return void, will now return this so you can do chaining.  The first place I’m implementing this pattern is in set().  With the latest SproutCore, instead of returning the value, set() now returns the receiver object.  Other property-related methods such as beginPropertyChanges() and endPropertyChanges() also do this.  This makes it easy to write compact code like this:


contact.beginPropertyChanges()
  .set('firstName','Charles')
  .set('lastName', 'Jolley')
  .endPropertyChanges();

Very compact!

What Do You Need To Change

Unless you’ve relied on the return value of set() in the past, you don’t need to do anything!  Just start enjoying the new compact syntax.  You don’t have to use it, but now it’s there for you.  If you have relied on the return value of set(), then you need to modify your code to use a separate get() on the method after you set it first.

The new SproutCore changes are available from git and SVN today and will be in the 1.0 release of the SproutCore gem.

 

A few mentions

I’ve been meaning to post these for a while, but SproutCore’s had a few good posts about it recently.

Here is an interview I did with InfoQ:

The most recent buzz on the web has been about Ajax and improved user experiences. Looking to the future, some suggest that the “old” client-server model will be the way to meet users expectations and demands. Could Client-Server computing be the follow-on to Web 2.0 technologies? - Client-Server Computing, the Future of the Web?

And a nice mention on TechCrunch:

MobileMe won’t be available until July, but you can at least get a feel for some of the service’s features by heading over to SproutCore and trying out their photo app. - Want to Try Out Apple’s MobileMe? Check Out SproutCore