You can create large scale applications in just a few lines of code in SproutCore thanks to properties, observers, and bindings. These three features work together to eliminate most of the “glue code” that ties together the various components of your app, and often makes up the bulk of a large application. By understanding how these features work, you will be able to make best use of the other components offered by the SproutCore API.

This topic describes in detail how SproutCore properties, observers, and bindings work and how you can use them in your own application.

About Properties, Observers, and Bindings

Properties, observers, and bindings work together to store the current state of your application and to relay changes in that state to the parts of your code that need to know about it. Here is a high level description of how they work together:

• Properties. A property stores some state in your application such as a contacts “firstName” or the “isEnabled” property of a button. Most properties are simple values such as a number, string or object – but they can also be written as functions that will dynamically “compute” the property value whenever you ask for it.
• Observers. An observer is a method that will be called whenever some other property changes. The methods often take action based on the new state, such as adding a view to the UI or sending changed values back to the server.
• Bindings. Bindings are a concept borrowed from Cocoa whereby the property of two objects can be “bound” together so that whenever one binding changes, the other one will change also. Bindings are a way to hook together loosely coupled parts of your application such as your models, views, and controllers. By using bindings, you can make your application easier to maintain and ensure all of the relevant components stay up to date.

The diagram below shows how these three functions interact in a typical application to update a text field when the firstName property of a model object changes. firstName and value are both properties that are bound together with a binding. Whenever you change the contact.firstName property, the binding will update the textFieldView.value property with the same value. This will trigger the valueDidChange() observer, which updates the views visible content to reflect the new value.

Using Properties, Observers, and Bindings In Your Application

Applications written with SproutCore usually contain very little “glue code” found in most other frameworks to relay changes to/from your model objects. Instead, you should design your application as a series of small components that each expose their current “state” as properties. Other parts of your application can interact with each component by changing properties directly or by hooking properties together directly using bindings. This design can eliminate a great deal of code in your application while also making your code easier to test and maintain since you can deal with each component in isolation.

Internally, the components you write should use observers to respond to changes to their own properties. The components should also update their properties to reflect their current state. For example, a typically CheckboxButtonView might be designed with the properties and methods shown in the dialog below.

In this class, the value property represents the current value of the checkbox (a boolean value; true if the checkbox is selected, false otherwise). The isEnabled property determines if the checkbox is enabled or disabled. Internally this class implements one observer – called isEnabledObserver() – that will be notified whenever the isEnabled property changes so that it can change the appearance of the checkbox. The class also implements a mouseDown() method that will respond to mouse clicks and change the value property accordingly.

Objects in your application can still implement traditional methods, of course. For example, if you have a model object that needs to save its changes to the server, you will often implement a commitChanges() method that takes care of the saving for you. This method does not use any of the property, observers, or bindings infrastructure.

As a typical rule of thumb, you should use properties, observers, and bindings for those parts of your application you would normally write a getter/setter for in other languages or frameworks. If the function you are trying to implement does not fit this pattern very well, you should use a normal method instead.

What’s Next

Now that you’ve read this introduction, you’re ready to dive deeper into each subject. Review the chapters below for details on properties, observers, and bindings and then read the chapter on how to properly design a SproutCore object to make the best use of this feature.

- Documentation forthcoming.

Related Links

About SproutCore Property Paths – more information about the how property paths are used to reference objects in SproutCore

Comments

No comments