Previously, you would have had to install SproutCore and run it locally to view the Test Controls app and would have had to search the source code of that app to figure out how the Controls were configured.  Now you can visit http://showcase.sproutcore.com at any time and copy code snippets directly from within the page.  Even better, we’ve expanded the examples significantly to include all of the available Views and Controls with many more configuration examples.

On a technical note, the Showcase page is actually a SproutCore app itself deployed on Github pages.  The app is open-source and you can browse its source and contribute to it on Github.

In the coming weeks, we will work to consolidate the various SproutCore demos and deploy them on this page as well, ensuring easy access to up-to-date demos.

[edit] Due to a mistake in the included files of the published 1.8.2 gem, the gem needed to be re-built.  Therefore the current working version of the gem for SproutCore 1.8.2 is sproutcore-1.8.2.1.  Sorry for any confusion.

We are pleased to announce the release of SproutCore 1.8.2. This release contains minor fixes to the 1.8 code-base and will likely be the last patch of 1.8 prior to the 1.9.0 release. To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

• Fixed syntax error in Datastore unit test.
• SC.SplitView can now mixin SC.SplitChild.
• Thinned picker pane border divs so that they don’t overlap the content view.
• Prevents target property conflict when configuring button targets with SC.AlertPane.
• Changed the aria-orientation of horizontal SC.ScrollView to ‘horizontal’ from ‘vertical’.
• Allows SC.CollectionFastPath to work with sparse content by always returning an item view even when content isn’t yet available.
• Prevents SC.GridView from iterating over its content array in order to work with sparse content.
• The ‘mobile-safari’ body class name is no longer being added in all browsers.
• Enables pasting in SC.TextFieldView to notify that the value changed.
• Prevents default touch behavior being intercepted on <textarea> and <select> elements.

gem update sproutcore

If you installed SproutCore using the installer, please note that due to the strain that maintaining the installers puts on the release process, we will not be updating the installer for each patch level release.   Therefore, to get the very latest stable version, it is recommended that you install the SproutCore gem.

Installing the gem is actually quite easy and there are detailed instructions for each platform at http://sproutcore.com/install/.  Simply find your platform and go to the Advanced Install tab, which helps you get Ruby properly installed.  If you’ve already got Ruby 1.9 installed, it is as simple as gem install sproutcore.

This is a patch level release and contains the following bug fixes:

* Documentation fixes.
* Fixes the timeout proxy settings: :inactivity_timeout & :connect_timeout. Setting them in a Buildfile proxy statement allows the developer to extend the timeout for the connection to be setup and for activity to occur.
* Adds missing CSS for SC.PickerPane left and right pointer.
* Tidies up index.rhtml template:
  - removes self-closing HTML
  - renames app.manifest to manifest.appcache
* Fixes the styling of ModalPane backdrop for SC.PanelPane.
* Fixes regression with Firefox specific SC.TextFieldView CSS.
* Improves use and compatibility of SC.TextFieldView:
  - applies 'autocapitalize' and 'autocorrect' attributes to all browsers
  - automatically centers hint text
  - fixes problem centering input elements in IE8
  - fixes problem positioning hint in textareas
  - improves readability of hints by making them antialiased in Webkit
* Fixes issue when subsequent attempts to load a failed/aborted image will result in queue processing being stalled.
* Fixes nesting SC.ScrollViews not passing mousewheel events from child to parent scroll view when child can no longer scroll.
* Fixes styling problem with SC.ListItemView right-icon.
* Fixes SC.StaticContentView not removing previous content when setting content to null.
* Fixes Safari focus ring artifacts in panes and Chrome bug with non-HW accelerated animations in render layers, by removing the default .sc-pane --webkit-transform: translate3d(0,0,0) CSS. This also makes it possible to accurately manage which parts of the page should become layers, because making everything a layer is not optimal.

To view the individual changes, check out the 1-8-stable branch on github.

More importantly, please join us in thanking Tim and Wesley and all the Committers and Reviewers for the work they’ve done to get us here.  We ask a lot of our burgeoning team and we are fortunate to have such people.

To install the latest version of SproutCore, visit http://sproutcore.com/install/ to get an updated installer for your system or if you are using the SproutCore gem, simply run:

gem update sproutcore

Thoughts on SproutCore

But before I get into some of the technical details of 1.8, I wanted to give a brief update on the status of the project.  I want to do this, because this release is about more than the code, it’s also about marking a milestone and making a statement.

The milestone is that this is the first major release of SproutCore after the project’s most active backer disappeared and the statement is, is that the SproutCore community is stronger than ever!

I cannot begin to express my enthusiasm for the way that the community has pulled together to make this release happen.  When I was asked to take on more of the care and feeding of SproutCore, Charles Jolley and I introduced a number of policies that were supposed to ensure that SproutCore never fell into the same predicament again. But I don’t think anyone knew how successful these changes would be until today.

Although I generally like to sit on my opinions for as long as possible, I feel that this is a time to be firm.  I say SproutCore is not only the most complete JavaScript application framework, it is, or at least is going to be, the application framework with the strongest open source community.  And this is why:

Yes, we have been through a rocky period and like any period of transition, it was accompanied by a flurry of activity and opinion on what should become the new reality.  Most of the ideas came from those that believed change should be immediate, that we could simply cast off any previous concerns and leap frog into a new future.

This is of course, a pipe dream.  If we stopped building consensus and instead chased easy opportunities, we may generate hype, but the real issues, the issues of building trust; of fostering and supporting a community of experienced SproutCore committers and developers; these real issues would be completely unaddressed.  True change doesn’t take radical ideas, it simply takes hard work, endurance and keeping a clean house where good ideas can grow, and that is what I believe SproutCore 1.8 represents.

We have a core of developers that are professional enough to put aside the fun and fancy of leaping at ideas in order to knuckle down on the unglamorous and tedious work that makes a framework truly great.  Things like improving documentation, adding rigor to tests and following proper deprecation procedures.  We will bring in good ideas, but we won’t sacrifice quality to do so.

Highlights of Version 1.8.0

So please forgive my long opinionated introduction and let me point out some of the latest highlights.

• A brand new exceptionally detailed three part introduction to SproutCore.
• A new reference guide on the build tools.
• Many many bug fixes. See the CHANGELOG for a complete breakdown.
• The beginnings of a major clean up initiative includes several deprecations.  Look for console warnings to indicate deprecated functions and check the CHANGELOG for the full list of deprecations.
• The Desktop framework has been thoroughly updated to include correct WAI-ARIA attributes for improved compatibility with assistive technologies.
• Get a basic statechart structure in new projects using the –statechart switch with sproutcore init or sproutcore gen app.
• Statechart States can be made to represent a route (by default SC.routes routes) and if assigned, the state will be notified any time the app’s location changes to match the state’s assigned route.
• Addition of SC.StatechartDelegate mixin. Apply this to objects that are to represent a delegate for a SC.Statechart object. When assigned to a statechart, the statechart and its associated states will use the delegate in order to make various decisions.
• Added the ability to dynamically add substates to a statechart via a state’s addSubstate method.
• TextFieldView has a new property, hintOnFocus, which uses a div to act in place of the regular ‘placeholder’ so that it remains visible while the text field has focus.
• Rewrite of SC.browser, which matches more browsers correctly and replaces the potpourri of various properties with seven standard properties: device, name, version, os, osVersion, engine and engineVersion.  For possible values, see the matching constants: SC.BROWSER, SC.DEVICE, SC.OS, SC.ENGINE.
• APP_IMAGE_ASSETS is a new global array that contains the list of all sprited images, this is ideal to preload images at different points.  For example, even before the app or SproutCore finishes loading.
• Sprites generated using @include slice(s) are now optimized to use space in the most optimal way to reduce memory foot print generated by a lot of extra transparent space.
• Added a security feature for dev environment. By default sc-server can only be used from your local machine unless you set the flag –allow-from-ips.
• Made sc-server non-blocking to work with long-polling requests.
• Allow longer timeouts in sc-server proxy by setting connect_timeout and inactivity timeout in the Buildfile.
• See the CHANGELOG for the full list of changes.

Finally, just thanks again to everyone that has made this release possible.  No matter if it was only a small part, I truly hope you feel pride in knowing that every part was essential.

Please use the mailing list sproutcore@googlegroups.com for all comments and questions.

• Name:  SproutCore 1.8 Release Sprint
• Dates:  Friday, Feb. 24 through Monday, Feb. 27, free-form style
• Topics:  Will include both code and doc tasks. Please follow the wiki page:  https://github.com/sproutcore/sproutcore/wiki/1.8-Release-Sprint

Aside:  We’ve decided that the next release of SproutCore will be titled 1.8.  It’s simply an indication that the code base has changed enough since the 1.7 beta, which should have been finalized some time ago but was missed during the rocky period when SproutCore 2.0 was determined no longer to present the future of SproutCore.

For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get another Reviewer’s feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.

As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and sproutcore@googlegroups.com and show them your support.

Today, I’m pleased to announce that several people have already graciously accepted the offer to take on roles and contribute even more towards shaping the future of SproutCore as the best application development framework, period.

Please join me in welcoming:

Jason Dooley,
Jeff Pittman,
Tim Evans, and
Wesley Workman

as the first SproutCore Committers and

Geoffrey Donaldson

as a new SproutCore Reviewer.

Undoubtedly, you will have come across these individuals on IRC and the mailing lists and will recognize them for their commitment to SproutCore and to the community. We are very excited and lucky to have them onboard.

In the future I expect to write many more posts like this, so to those that wish to be included, keep contributing, keep learning and we hope to hear from you soon.

Change 1: SproutCore 2.0 Is Now Amber

SproutCore 2.0 started out as a rebuild of SproutCore around a more modular and modern design. Since then, the project has evolved in a different direction that means it will never be a complete replacement for SproutCore 1.x.

Therefore, we have decided to rename SproutCore 2.0 and manage it as a separate project. The new project will take on the original code name – Amber. It will be run by Yehuda Katz, Tom Dale, and Peter Wagenet.

The Amber guys are working on a new website and complete update for the new project. When they are ready we will post a link to the blog here so you can find out more about it. In the meantime, work on this project is continuing in the sproutcore20 repository on Github.

Change 2: New Contributor Process

With the Amber change, SproutCore will now once again be the sole domain of those wanting to create fast, native style applications on the web based on the SproutCore 1.x code base.

There is a very active community of developers who have invested heavily in this area. But, due to the structure of our governance system (via a Core Team), we haven’t done a very good job at making it easy for members of the community to get actively involved.

As of today we are adopting a new contributor process that will change all of this. The new process is based on the Reviewer/Committer model used by WebKit and several other big projects. It is fully documented on the SproutCore wiki, but here are the highlights:

• All SproutCore projects will have reviewers and committers. Reviewers have the authority to approve changes to the code, committers can commit code when it is approved by a reviewer.
• Anyone can become a committer once they have had a few patches accepted and a reviewer is willing to sponsor them. Anyone can become a reviewer once they have experience as a committer and the majority of other reviewers votes to approve them.
• There is no longer a “Core Team”. Instead, we expect reviewers and committers to agree as a group on directional changes to the project. All discussions will be held on the sproutcore-dev mailing list or in IRC. We will avoid private mailing lists.

The goal is to make it possible for anyone who is willing to put in the time and effort to contribute to SproutCore to become a leader in the community. You don’t need a secret handshake to get in – just contribute.

To get this process started, we have identified a group of people – both former Core Team members and others – who qualify as either Committers or Reviewers and reached out to them. You can see the list of those who have already accepted on the wiki. If you aren’t on the list and you want to be, please email Tyler Keating and he will help you out.

Change 3: New Leadership

Finally, I want to talk a bit about my own role in SproutCore. Over the last year, my job has evolved to include a lot less coding and more other activities. While I am still very passionate about seeing SproutCore grow, I am not able to provide the kind of detailed attention that the project needs on a day-to-day level.

Part of the solution to this is to move towards the community driven contributor process above so that no one person can be a bottleneck anymore. We also need someone who has shown dedication to the community to help lead the process.

Tyler Keating is an independent developer who has been contributing to SproutCore for the last four years. He has shown dedication to the project and a desire to get others involved that is just what SproutCore needs.

Therefore, Tyler has agreed to become the new administrator for SproutCore. He is the main guy you should now contact with questions about managing the project day to day. I am going to remain as an honorary project owner so I can chime in on directional things.  In general though, I hope SproutCore can become more community directed than it has been in the past.  Tyler is here to help facilitate that.

Open source is only as strong as the community around it. I have been proud to get to work with some of the best technical talent on the planet through SproutCore. Thank you everyone for your contributions over the last several years.

SproutCore exists to serve your needs. Get involved and make it your own!

PS. I am posting a similar version of this post to the SproutCore mailing list where we can discuss this in the open.  Please feel free to join in there.

The following post refers to SproutCore 2.0, which has split off as a separate project. However, the information within this post is entirely applicable with respect to using SC.TemplateView and Handlebars in SproutCore 1.8. If you wish to use SC.TemplateView in SproutCore, you only need be aware that the many views and controls in the Desktop framework may contain templates, but should not themselves be contained within templates.

When people check out SproutCore 2.0 for the first time, one question that they frequently ask is: Do I have to use Handlebars?

Handlebars, if you’re not familiar with it, is a semantic templating language written entirely in JavaScript. It’s an expressive language with a tag syntax reminiscent of HTML, except expressions (oftentimes referred to as “mustaches”) are wrapped in double-curly braces. A simple template might look like this:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>

Handlebars, unlike other templating solutions like Eco, doesn’t tempt you to embed domain logic in your HTML. Anything other than simple conditionals and loops must be contained in your application’s JavaScript, which enforces the separation of concerns and leads to better testability. The language is also extensible with custom helpers, which allows you to effectively write a template DSL for your particular application.

So, while the answer to the question is use whatever templating system you’d like, we think Handlebars is a great option. Perhaps most importantly, we’ve spent a lot of time deeply integrating SproutCore and Handlebars, such that you get a lot for free just by using bindings, computed properties, and the SproutCore object system. In fact, while we like the features and simple-yet-expressive syntax of Handlebars, the real reason we chose it when creating SproutCore 2.0 was because of its speed and architecture, allowing us the kind of integration that would be very difficult with other templating libraries.

Handlebars compiles a given template only once. After that, it generates a JavaScript function that can be executed repeatedly without the expense of re-parsing the template. For example, a template like this:

{{#if arrived}}
	Hello,
{{else}}
	Goodbye,
{{/if}}
{{name}}!

might be translated into a function like this:

function() {
  var arrived = this.arrived,
      name = this.name,
      result = '';
 
  if (arrived) {
    result += "Hello, ";
  } else {
    result += "Goodbye, ";
  }
 
  result += name+"!";
 
  return result;
}

(Please note that the generated code looks different; this is just illustrative of the effect.)

Because you declare your intent, Handlebars knows how to generate the JavaScript that gets executed at runtime. If your templates don’t change, you can precompile the templates into JavaScript during the build process for additional speed and file size improvements. It also means that, as Handlebars is optimized, so is your application.

But most importantly, because of its declarative nature, we can make your templates bindings-aware. Here’s where the real advantage appears: you never have to write code that updates the DOM. Most other frameworks require you to have two separate code paths: one that creates the initial representation (often via a templating solution), and one to update it, usually with something like:

$('#welcome').text("Goodbye, "+this.name);

With SproutCore and Handlebars, both behaviors are contained in the same template.

But beyond simple values, we also support things like conditionals and loops. If you use the {{#each}} helper to print an array, for example, the DOM will update automatically whenever items are added, removed, or modified. This eliminates lots of boilerplate and common bugs from your application, and it means you don’t need to anticipate all of the places data may change and manually re-render. Just modify the array (or the contents of the array) and let Handlebars take care of the rest.

So, while we encourage you to use whatever templating system makes most sense to you, we think that using the built-in Handlebars integration will let you write less code—and have fewer bugs—by eliminating the tedious boilerplate that you’re used to writing.

You can expect many improvements to these auto-updating templates as time goes on. In particular, we are focused on ensuring they work flawlessly with elements, such as <tr>, that have strict requirements about their enclosing tag. Yehuda and I have been working on metamorph.js, which we are in the process of integrating into SproutCore 2.0, that will both improve compatibility with these kinds of elements, as well as offer performance improvements. Look for these commits to SproutCore soon!