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.

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!

In this example, I’ll assume a standard REST backend. To make things easier on you, I’ve made up a basic one in Rails. You can grab it with:

git clone git://github.com/sproutcore/todos-server.git --recursive

If you just want to grab the completed SC code you can run:

git clone git://github.com/sproutcore/todos.git -b server

Anyway, lets dive into the code. All of our work is based upon the original SC2 To-Dos app, and I’ll walk through how we get from there to our completed AJAXified app.

Fetching from the Server

The first step is to fetch a list of our to-dos from the server. Here’s the code to do that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Todos = SC.Application.create({
  ready: function(){
    this._super();
    this.fetchTodos();
  },
 
  fetchTodos: function(){
    $.ajax('/todos.json', {
      success: function(data){
        Todos.todosController.beginPropertyChanges();
        data.forEach(function(item){
          item = item.todo;
          var todo = Todos.Todo.create({
            id: item.id,
            title: item.title,
            isDone: item.done
          });
          Todos.todosController.pushObject(todo);
        });
        Todos.todosController.endPropertyChanges();
      }
    });
  }
});

The fetchTodos method is simpler than it looks. We’re making an AJAX call to “todos.json” which returns an array of todos that looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[
  { 
    todo: {
      done: false
      id: 13
      title: "Todo One"
    }
  },
  {
    todo: {
      done: false
      id: 14
      title: "Todo Two"
    }
  }
]

(Rails actually throws in a few additional fields, but we can ignore those.)

Once we get the data, we loop over each item and create a new Todos.Todo, adding it to Todos.todosController. Since our views are bound to the controller, as soon as these items are pushed, our page displays a list of our To-Dos.

Creating Records

Now that we’ve been able to fetch a list from the server, it would be nice we could actually add new records. We’ll begin by adding a save method to our Todos.Todo class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Todos.Todo = SC.Object.extend({
  // ...
  id: null,
 
  attributes: function(){
    return {
      title: this.get('title'),
      done: this.get('isDone')
    };
  }.property('title', 'isDone').cacheable(),
 
  save: function(){
    var self = this;
 
    $.ajax('/todos.json', {
      type: 'POST',
      data: { todo: this.get('attributes') },
      dataType: 'json',
      success: function(data) {
        self.set('id', data['todo']['id']);
      }
    });
  },
  // ...
});

Next, we modify Todos.todosController.createTodo to save the new to-do:

1
2
3
4
5

createTodo: function(title) {
  var todo = Todos.Todo.create({ title: title });
  this.pushObject(todo);
  todo.save();
}

Now, when we create a new to-do, it will be automatically saved. If you refreshed the page now, you’d see the same list reloaded.

Updating Your Records

We’re doing well so far, but once we’ve created our record, we’re not doing any updates. Lets modify our code to automatically save any changes to the to-do:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Todos.Todo = SC.Object.extend({
  //...
  isNew: function(){
    return !this.get('id');
  }.property('id').cacheable(),
 
  save: function(){
    var self = this,
        url = this.get('isNew') ? '/todos.json' : '/todos/'+this.get('id')+'.json',
        method = this.get('isNew') ? 'POST' : 'PUT';
 
    $.ajax(url, {
      type: 'POST',
      // _method is used by Rails to spoof HTTP methods not supported by all browsers
      data: { todo: this.get('attributes'), _method: method },
      // Sometimes Rails returns an empty string that blows up as JSON
      dataType: 'text',
      success: function(data, response) {
        data = $.trim(data);
        if (data) { data = JSON.parse(data); }
        if (self.get('isNew')) { self.set('id', data['todo']['id']); }
      }
    });
  },
 
  autosave: function(){
    this.save();
  }.observes('attributes')
});

That was pretty easy. The main work was modifying our save method so that it’s able to handle both updates and creates. We also added a nifty little autosave method that checks for any changes to our attributes and calls save automatically. The power of bindings really shines here.

The only thing left to do now is to delete to-dos.

Deleting Records

For this we need to add a destroy method to our to-do and update Todos.todosController.clearCompletedTodos to call it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Todos.Todo = SC.Object.extend({
  //...
  isDestroyed: false,
 
  destroy: function(){
    var self = this;
 
    $.ajax('/todos/'+this.get('id')+'.json', {
      type: 'POST',
      data: { _method: 'delete' }, // For Rails
      dataType: 'text', // Handle blank strings
      success: function(){
        self.set('isDestroyed', true);
      }
    });
  },
  //...
});
 
Todos.todosController = SC.ArrayProxy.create({
  //...
  clearCompletedTodos: function() {
    var self = this;
    this.filterProperty('isDone', true).forEach(function(todo){
      self.removeObject(todo);
      todo.destroy();
    });
  },
  //...
});

Now, when you click “Clear Completed Todos”, they’ll also be removed on the server.

Wrapping Up

As you can see, most of our code wasn’t even server interaction, it was just making sure we notified the server at the right time. The server interaction was just some simple AJAX calls, made even simpler with jQuery. If you look at the code I provided on GitHub, you’ll notice that I have a series of conditionals to check for whether the record is in the process of saving or being destroyed. This helps to make sure that we don’t send duplicate create or delete requests or send conflicting saves. I hid all of that along with the error handling code to help focus on the key aspects of server interaction.

Socket.IO! I Choose You.

There is actually some nice stuff that happens in Hubbub in real time if you have the app open. For example, if someone sends you a message, signs out an item to you, makes a new item available, or any number of other events occur, then the application updates instantly without requiring a page reload. Sure it’s not new, but with Socket.IO and SproutCore it’s also not a difficult-to-implement kludge.

So for those that haven’t yet tried it, Socket.IO is available here. There are really good instructions on using Socket.IO on their site, but it’s so simple I will include my entire setup here.

My Setup – Server Side

Hubbub’s app server is written with Node and Express. So after installing Socket.IO, there’s nothing more to getting it working server-side than:

app = require('express').createServer({key: …, cert: …, ca: …});
io = require('socket.io').listen(app);
app.listen(3443);

Note: I use port 3443 locally with TLS/SSL encryption, which is not strictly necessary.

My Setup – Client Side

On the client side, you need to first retrieve the Socket.IO JS from the server. Initially, I added the Socket.IO script to my copy of index.rhtml directly above the javascripts_for_client statement. This simply pulls the JavaScript from the server on page load like the Socket.IO default examples show and if you want to do the same and aren’t using a custom index.rhtml, then the instructions for copying index.rhtml are listed at the top of the original file.

However, I’m just not satisfied with Hubbub being anything less than the best application it can be, and the first improvement I made to reduce loading times was to load Socket.IO dynamically. Without getting into the details of how I use Statecharts, the application begins basically like this:

Initial States Diagram

Notice that I don’t load Socket.IO until the application reaches the Ready state. The following details describe exactly how I’ve done this.

1. Directory Structure

To make Socket.IO available to all the apps in my Hubbub project, I wanted it to be its own framework. The relevant directory structure I used is this:

hubbub/
   frameworks/
      socket.io/
         modules/
            io/
         resources/

I then copied socket.io.min.js and WebSocketMain.swf from ./node_modules/socket.io/node_modules/socket.io-client/ into my project like so:

hubbub/
   frameworks/
      socket.io/
         modules/
            io/
               socket.io.min.js
         resources/
            WebSocketMain.swf

2. Buildfile

The files are now where I want them, but SproutCore’s build tools won’t load anything in the frameworks or modules directories unless told to do so, plus I still need to proxy the Socket.IO traffic to my local development server. Here is the relevant part of my Buildfile:

config :hubbub,
   :required => [
      :'socket.io'
   ],
   :deferred_modules => [
      :'socket.io/io'
   ]
 
proxy '/socket.io',
   :to => 'localhost:3443',
   :secure => true, # Hubbub is entirely over HTTPS
   :timeout => 25 # A longer timeout for polling transports

I’ve required :'socket.io' here as an example, which isn’t strictly necessary. The reason you may want to do this is so that frameworks/socket.io/resources/ will be included in the builds, and therefore if you were to use flashsocket as a transport mechanism, you would be able to set WEB_SOCKET_SWF_LOCATION = sc_static('WebSocketMain.swf'); (see the Socket.IO FAQ).

Also notice that the socket.io/io module is deferred. Therefore it won’t be fetched until we tell SC.Module to do so. That way, we can pass through our initial application states without any background loading interfering with the more important task of getting people into the app as quickly as possible.

3. Load the Code

Finally, to load Socket.IO I added the following to Hubbub’s READY state:

enterState: function() {
 
      // Load Socket.IO and initialize it when it is ready
      SC.Module.loadModule('socket.io/io', this, this.initializeSocketIO);
 
    },
 
    initializeSocketIO: function() {
 
      socket = io.connect('https://localhost:3443');
 
      socket.on('connect', function() {
        // ... for a later post

Cool Beans

At this point, I see the following in my development console after reaching the READY state:

SC.Module: Attempting to load 'socket.io/io'
SC.Module: Module 'socket.io/io' is not loaded, loading now.
SC.Module: Loading JavaScript file in 'socket.io/io’ -> '/static/socket.io/io/en-ca/current/javascript.js?1315847166'
SC.Module: Module 'socket.io/io' finished loading.
SC.Module: Evaluating and invoking callbacks for 'socket.io/io'.
SC.Module: Module 'socket.io/io' has completed loading, invoking callbacks.
RTM: Welcome to Hubbub Real Time Messaging

And that my friends, is that! An extra 42KB of data and processing that does not detract from the application start up. See it in action at https://hubbubapp.com . You’ll need to get one of your Borrowers online at the same time as you.

One of the biggest knocks against SproutCore 1.x is that it is a “big, monolithic framework”. You end up pulling in more than you’re ever going to use or need. This is a problem, particularly in a JavaScript context, because it increases the size of the file that needs to be sent down from your server, and then parsed by the browser. Particularly in a mobile context, this can be a serious performance drain.

Enter the SproutCore whitelist/blacklist. If there is a section of SproutCore 1.x that you’re not using inside of your application, you can use either a whitelist or a blacklist to tell the build tools not to include that code in the final packaged version of your application’s JavaScript. So for example, if my application is not using collection view, I could create a file called Blacklist inside of the root of my file directory, and put the following into it to exclude collection view:


{
"/sproutcore/desktop": "views/collection.js"
}


“/sproutcore/desktop” is the “target” for the build tools, which you can think of as basically the framework to target. Then, “views/collection.js” which is the “rule” for the build tools. If the list is a whitelist, then the rule would mean to include the file in the final build, whereas if the list is a blacklist, then the rule would exclude that file. So in this case, “/sproutcore/desktop”: “views/collection.js” tells the build tools to exclude the file “views/collection.js” from the desktop framework.

So if you have a 1.x app and you’re looking to improve the initial load time of your app, I would create a blacklist for your application, and go file by file seeing what you can exclude from the framework. Happy optimizing.

When developing applications, localization and internationalization are things that are easily overlooked and forgotten until the very end. In the case of smaller applications, they are targeted to only one language, and not having to account for localization or internationalization might work out in the end.

However, especially for larger applications or applications that are targeted to several international markets, planning and implementing an application with localization and internationalization is extremely important. Without proper planning, you can get into a lot of trouble that could have been alleviated with very little upfront effort. The type of planning you’ll need to do is what we’ll go over in this in this post.

Factor in localization early in your development cycle!

As a developer, you should plan for localization and internationalization early in your development cycle, when it is easy to deal with. Once an application grows too large, it is very difficult to add localizable strings.

If you develop without taking into account localization, often text winds up hard coded and, as with any application, these strings are found in a million different places. Having to track down all the non-localized strings after the fact is time consuming and unnecessary if accounted for earlier in the project.

Localizing Your Apps with SproutCore

SproutCore makes it easy to localize your application. Using a strings table for each language, developers can enter key-value pairs. These keys are generic and are referenced throughout the application.

When the application runs, instead of using the actual string in the view, SproutCore looks up the correct localized value from the strings table. This makes it easy not only to localize the application, but also to manage all of the strings in your application because they are all located in one place. If you need to finalize the strings, you can send that off to be finalized without having the stakeholders know any JavaScript.

However, there are more things to localize than just strings. For each language or locale, you can have a sub-directory that contains not only your strings file, but also other resources such as images, CSS, and HTML templates. We’ll go into more detail how to properly set up your application for localization in the next section.

Set Up Your Application for Localization

Now that you’re thinking about localization, how do you go about setting up an application to be localized? There are some things that will need to be expanded upon from the normal directory structure that you are familiar with.

The directory structure

The first thing to go over is the general structure of a SproutCore application as it is normally presented when you create a basic app. Below is the directory structure for an application, MyApp, that contains an image, myapp_logo.png inside of the resources directory that contains some English text, and the normal en directory with CSS and a strings file. Most of time the, the strings file will be empty because the developer hasn’t considered localization.

apps/
   myapp/
      core.js
      en/
         strings.js
         myapp.css
      main.js
      resources/
         images/
            myapp_logo.png

However, this is not very localizable. Let’s say that we also want the application to be available in German. In this case, we’ll have to readjust the directory structure a bit.

First, the image in the case has some text that needs to be in German. Second, there is some CSS layout that needs to be readjusted for the really long German words. Third, and most important, there are a lot of strings that need to be translated, so we need to create a strings file.

apps/
   myapp/
      core.js
      en/
         strings.js
         myapp.css
         images/
            myapp_logo.png
      de/
         strings.js
         myapp.css
         images/
            myapp_logo.png
      main.js

In this structure, when you run the application in English, only the contents of the “en” directory will be loaded and vice versa for German. Therefore, you can optimize the code loaded for the specific language.

About Those Language Codes

The language codes that are used in a SproutCore application are standard internationally recognized language codes in the format: ‘language_REGION or just ‘language’. For instance, if you want to localize your application into British English and American English, you would have two localizable directories: en_US and en_UK.

The strings.js File

At the heart of the localization system that SproutCore provides is the strings file. Each language has its own file in its respective language directory. It is important to note that only the strings file in the language that you’re running will be loaded for any given language when the application runs.

Basically, the string file is a lookup table for a string key, which you reference in your application code, and a string value, which is the corresponding localized string for the key.

The strings file has a specific format that you will need to follow:

SC.StringsFor('en_US', {
	'key': 'value'
});

Localizing Your Application

Now that you have everything set up, you can write your localizable application. Whenever you create a view element using either a SC.View or a SC.TemplateView, it is likely that you will need some text to go with it.

Instead of putting in some hardcoded text, even if it is temporary, you should create a key and add that to your view element and a corresponding value in your strings file, regardless if it is final or not.

What is the Best Practice to Create a String Key-Value Pair?

There isn’t a hard and fast rule on how to create a string key, but as long as you come up with a consistent formula, it will work out in the end. One way to do it is to refer to the path of the view inside your application.

For example, if you have a list view in the application that has items with a title, you could name the string key something like MyApp.List.Item.Title. While this seems verbose, any developer who looks at your view will know what the key stands in for.

Another tip is that if a string is not finalized, you should make it stand out clearly in the UI until it is finalized. One way to do so is to precede it with an underscore: _MyApp is a great way search for beanie babies. Once that string is approved by the stakeholders, you can easily remove the underscore.

Localization in SC.Views

Several of the built-in SproutCore SC.Views have support for localization. for example, you can pass in localization string key into a SC.LabelView:

MyApp.TitleLabel = SC.LabelView.extend({
	localize: YES,
	value: "MyApp.TitleLabel"
});

Using the .loc() Function for Computed Strings

To understand how to do more complex localizations with passed-in properties, it is important to know how the .loc() function operates. In many cases it is run for you by SproutCore, but there are cases where you want to do something more dynamic.

The .loc() function takes optional parameters like the .fmt() function. For example, let’s say that you have a computed property on a customized SC.TemplateView that represents a list item. You want this list item to be more dynamic, showing a localized string with some parameters; note that the order of the parameters may be different in different languages.

The key-value pair is the following: “MyApp.List.Item.Title”: “%@1 employees working for %@2″

list_item.js view:

1
2
3
4
5
6
7
8
9
10

	MyApp.ListItem = SC.TemplateView.extend({
		templateName: 'list_item',
		localizedTitle: function() {
			var content = this.get('content'), ret = '';
			if(content) {
				ret = "MyApp.List.Item.Title".loc(content.get('employeeCount'), content.get('managerName'));
			}
			return ret;
		}.property('*content.employeeCount', '*content.managerName').cacheable()
	});

list_item.handlebars template:

{{localizedTitle}}

Now, the computed ‘localizedTitle’ property will be used inside of the template and properly format for any language.

Localizing Simple Values in Templates

In SC.TemplateView templates, there is a handlebars helper that allows you to easily localize strings without having to use a computed property. Computed properties only need to be be used if there are complex properties. In the case of a simple static string, you can use the ‘loc’ helper in the handlebars template directly.

{{loc "MyApp.Path.To.Loc.String"}}

Conclusion

SproutCore provides a powerful way to localize your application into as many languages as you need. The main takeaway from this post should be that if your application might support multiple languages, plan ahead and do the right thing early on. If you don’t, it will be difficult to retrofit your existing application to support localization.

Read on for more information on the changes.

In the framework itself changes include:

• Safari Lion browser detection.
• Speed improvements
• Flag to stop PickerPane repositioning when resizing the window
• Option to enable or disable overflow in SegmentedView
• Support for autoCorrect and autoCapitalize in TextFields
• Minor improvements in SC.Statechart
• New SC globals to provide information like build mode, build number and locale.
• Lots of bug fixes

New features in the build tools include:

• When a stylesheet hits the 4096 CSS selectors limit in IE , the files will now be automatically split.
• Sprites are optimized to use less space
• Layout.js, which includes location metrics, will be always first when building the js files
• Added security feature for dev environment. By default sc-server can only be used from your local machine unless you set a flag.

Along with the following bug fixes:

• Sprites are again the default for abbot due to performance issues with data-uris in some browsers
• index.html will be minified again
• Whitelist and black list fixes
• Fixed iOS retina display styling

It was quite the night— we heard presentations from Majd Taby and Greg Moeck, followed by community Q&A. Majd started us off with a talk on how bindings help SproutCore make your application smaller, concluding with an impressive demo of his work on SproutCore Touch and TransformJS. Greg spoke about connecting SproutCore apps to your backend, and best-practice approaches based on your app’s structure.

Check out the videos below! Many thanks again to our friends at Nokia, who recorded the talks— note the improved video quality — and kept everyone happily fed with pizza, cookies, and refreshments for the night.

Hope to see everyone at the September meetup, back in San Francisco at Twitter!