This release focuses on gem fixes, as the SproutCore build tools are not compatible with Merb 0.9.5. You can install Merb 0.9.4 like this:
sudo gem install merb-core -v 0.9.4
In addition, Erich Ocean is now able to publish gem updates. Expect SproutCore 0.9.18 in the near future with tons of bug fixes and tests contributed by users over the last 3 weeks.
Build Tools
Ticket [158] Fix requirements to load correct version of merb (Paul Barry)
Ticket [124] Proxy doesn’t forward GET params with merb 0.9.4 (Lawrence Pit)
Framework
require() fixes Fix require()’s for server/rest_server.js and server/rails_server.js (Lawrence Pit)
A lot of folks ask questions about how to use controller’s in SproutCore. Well, now you have some answers. Thanks to rollerdexter who wrote up the majority of this article.
On August 31 I am getting married to my college sweetheart and taking a month-long honeymoon that will last until early October. Because of this we’ll be running “reduced service” in the SproutCore project in a few ways:
No Bay Area SproutCore meetup is planned for August or September. We will resume in October, unless someone else wants to pick up the effort to arrange a meetup during this time. Feel free to email us at contact@sproutit.com if you are interested.
No new releases of the SproutCore gem are planned until October. If an emergency release is required, Erich Ocean will be able to do so. In the mean time, you can still contribute patches and send me pull requests. I will integrate them when I return in October.
Thankfully, SproutCore is driven by a rapidly growing community of developers that extend well beyond myself so you can still find help for all of your SproutCore questions both on our mailing list and in our IRC channel #sproutcore (on freenode.net). If you have questions, please go ask!
This is a big moment for me and I appreciate your patience. Normal service will resume in October. I will do my best to answer all of my pending email at that time. SproutCore’s future is very bright and I’m really looking forward to the cool things we are going to do in the fall. Thanks everyone for your involvement!
John Resig announced some very good news about the future of JavaScript yesterday. The technical team at ECMA - TC39 - responsible for writing the spec for the next version of JavaScript (called variously ES4 or ES3.1) had effectively split in two, hindering any real progress towards producing a real spec. The result was that the group finally decided to jettison some of the ideas both camps had adopted and coalesce around a more evolutionary approach to JavaScript.
Despite whatever conflict might have caused this, the outcome is undoubtedly good for JavaScript developers everywhere. The ES3.1 spec add minor sugar while completely neglecting some of the glaring issues with the language. The ES4 spec, meanwhile, mutilated the language to the point of making it unrecognizable. ES4 would have both led to the removal of some of JavaScript’s most useful features while simultaneously telling the world to ignore JavaScript for another 5 years while the standard body in charge of it decided what they wanted it to become.
So thanks TC39, you’ve made a wise choice. Let’s hope your new middle path can fix the language without leaving its most powerful features behind.
Serving up static files is about as easy as it gets when trying to manage your server. That is one of the awesome advantages of using SproutCore in your deployed applications.
However, working with these static apps in development can do some funny things with your cookies. If you have run across any of these issues including having to authenticate every time you refresh then you will want to take a look at this by Mike Subelsky.
Warning: if you add any code to force authentication be sure it won’t carry into production!
Just a quick note that we released a version 0.9.16 of SproutCore today. This fixes a critical regression introduced in 0.9.15 that broke use of the :field option. The sample controls have also been updated to make sure we test for this in the future.
Some fine folks invited me to speak on SproutCore at Oracle this month and so I put together some slides and gave them a show. Many thanks to the great people there who let me speak. And by the way, they are doing some very interesting things so keep your eye on them.
Anyway, I can share these slides unlike some presentations I’ve done in the past. Enjoy.
O’Reilly’s InsideRIA blog has a great Introduction to SproutCore today. If you haven’t heard my talk on SproutCore before, this covers a lot of the same information. Thanks Toby!
Yet another use for Flash is headed for the dust bin…Firefox 3.1 will provide native support for <audio> and <video> tags, just like WebKit. It will still be years before these browsers have broad enough distribution to completely eliminate the need for plugins to handle audio and video, but the writing is on the wall…
A new SproutCore gem is rolling your way this morning and this one has some big milestones in it. There are some big changes both on the build-tools side and in the framework itself, so I will address both separately. Before I get to that though, a big “Thank You” to everyone who has contributed to this release. SproutCore has now taken commits from over 2-dozen people, which is pretty astounding given how new it is. Something this big is always a huge team effort and your work is greatly appreciated.
Build Tools
No more :outlet. When using the view helpers in your RHTML, you have in the past needed to add the :outlet => true option to any non-top level helper. This has caused endless confusion for new developers and was always a tad pointless since computers are good at automatic things like that. Starting with 0.9.15 you no longer need to add :outlet => true to your view helpers. SproutCore will figure out whether your views should be outlets or not. And there was much rejoicing.
Experimental HAML support.HAML is an interesting new templating language that seeks to make it easier to create HTML in less code. If you hate mixing HTML and the view helpers in your code, HAML might be a good option for you instead. Trek, who initiated this feature change, wrote a great blog post explaining HAML and how to use it in SproutCore.
Debug Directory Support. If you ever need to add some debug code to your app, you now have a place to put it. Create a debug directory in your client or framework and place your JS files in there. They will be included in development mode but excluded when you do a production build. The SproutCore framework now bundles the unittest.js code this way so you don’t have to load that code in production.
Framework
Introducing SC.Enumerable. Working with collections is always a big challenge in any framework. SproutCore in particular devotes a large part of its codebase to helping you efficiently download and display large collections of data. In the future, a lot of these features will depend on being able to treat objects other than simple arrays as collections, so we’re working on adding the API to support this. SC.Enumerable is one of the first steps in this direction. A blog post delving into this further will be forthcoming.
Reduced Properties. Along those lines, the framework now includes support for some special new properties that return summary information about a collection of data. For example, calling [1,2,3].get(’@max’) will return the maximum number in the array. Best of all, these properties are bindable so you can use them to display automatically update summary info in your UI.
New SC.RailsServer & SC.RestServer. The server classes are getting some love by Lawrence Pit who has given us both a RestServer and a RailsServer. If you are building with a REST or Rails backend, these can save you some coding time. See the online docs for more info.
And Much Much More
As usual, there are a ton of extra little fixes and updates included thanks to contributions from you! Here is the full list of changes:
Build Tools
Fixed bug that would sometimes convert “faked” HTTP methods sent for Rails apps into real HTTP methods, breaking Rails. (Ticket #115) [Lawrence Pit]
Experimental support for rendering templates using HAML (Ticket #114) [Trek, Lawrence Pit]
During sc-build, by default the build tools will now calculate a digest key to append to the end of URLs instead of simply using a timestamp. This will ensure that the URLs generated are properly cacheable even when building on different machines. [CAJ]
Regex for replacing occurrences of static_url() are no longer greedy. (Closes #87) [nciagra]
Added support for the autobuild config option. If specified, then the named bundle will be skipped when you run sc-build by itself. It will still be built if you name the bundle explictly (i.e. sc-build mybundle) or if you pass the -r option and the bundle is required by another bundle that is also being built.
Along those lines, the default config was also changes so that the doc tool and the test runner will no longer autobuild.
Added support for the build_languages config option. If specified, then simply runnig sc-build will automatically build all of the languages named here, even if there are no specific locatizations for said language in your project.
Added support for the debug directory. Any JS files in the debug directory will now be loaded in development mode but excluded from production builds. You can use this to include added instrumentation and benchmarks for use in dev mode.
Following with the debug enhancement, the SproutCore JavaScript now includes the unittest.js in its own debug directory so that this library will no longer be included in production builds.
Bundles are now reloaded on each request to the development server. This both allows the server to recover from exceptions when building a file and eliminates a memory leak that caused an eventual slow-down.
Eliminated need for :outlet option. And there was much rejoicing.
JavaScript
Added titleize() helper for Strings. Also imported various other helpers from Prototype.
Ajax requests sent by SproutCore’s SC.Server object will now add a custom header “SproutCore-Version: 1.0″ to every request. You can use this to detect requests coming from SproutCore on the server side. Fixes #85 [trek]
SC.Record does a better job of matching null values. Fixed #96 [Fredrik Blomqvist]
SC.Server now handles created records with no attributes yet. Fixed #98 [CAJ]
Added support for reduced properties. These properties begin with “@” and will automatically calculate some kind of summary information about the receiving array. They are also bindable so you can bind to myArray.@average and it will update whenever the average changes. [CAJ]
Cleaned up SC.Array support to incorporate new SC.Enumerable functions. The Enumerable methods from Prototype are no longer supported. [CAJ]
Removed Array.asArray(). This helper has been deprecated for 6mo now. Use SC.$A() or Array.from() instead. [CAJ]
Added SC.$A() helper. This works like Prototype’s SC.$A() except that it will work with any enumerable. It is also namespaced properly. [CAJ]
Added “application/json” to the default Accept header for all servers. Required for proper support of json format. [Lawrence Pit]
Added experimental support for SC.RailsServer which works with resource oriented Rails applications. [Lawrence Pit, Simon Harris]
[FIX] SplitView now resizes in both directions properly. Closes #110 [Christoph Angerer]
Added support for the SC.Enumerable mixin and SC.Enumerators. These items provide the basis for our standard enumeration API. This will replace relying on iterators provided by Prototype eventually. See docs on those classes for full information. [CAJ]
SC.guidFor() now works consistantly with strings, numbers and other primitive objects. Before it would differentiate between different instances of these objects. Now it treats them the same if they are the same value. [CAJ]
Added SC.hashFor() method which can be used to determine if two objects are equal. Normally this returns the same value as guidFor() but if you implement the hash() method on your object, it will return that value instead. This gives you an easy way to indicate that two objects are equal even if they are different instances. [CAJ]
Updated SC.isEqual() to respect SC.hashFor().
Added support for hasSelection, hasContent, and other useful properties on controllers for activating UI.
Added newObject() and insertNewObjectAt() methods to ArrayController. These methods will create and register new records automatically.
SC.Record’s changeCount now increments whenever a member array’s attributes change.
Optimized SC.Object.objectForPropertyPath() to use less memory.
You can now pass a string path as a :target and it will be converted to an object. (thanks Peter Blazejewicz!)
SC.CollectionView will now call destroyObject on the content array instead of removeObject if that method is defined. This allows you to implement arrays with a more specific handling of the destroyObject method.
Added support for checkbox views in ListItemViews. Since this is a fairly common requirement, checkbox views are now built in.
