It is very apparent that in order to “get” SproutCore you have to understand a bunch of fundamental concepts, such as how key-value observing (KVO) and bindings work. For someone like myself, I need to work on the fundamentals and have it both verbally and visually explained. For example, one of the most basic concepts seems to be binding a view’s properties with some model object’s properties. Seems trivial enough. However, I kept getting confused how to really connect a view with a model. the examples I would see online always showed something like for view V that has a property called “value” and a model object M that has a property called “value”, you would hook the two together as so:
Where the above wiring happens when you create an instance of the view V. I kept asking myself, well what happens if the model object doesn’t have a property named “value”? Then what? What if you want to make a generic view that doesn’t know anything about the properties of some given model? How then to do you bind/wire/hook the two together? Turns out with SproutCore’s bindings the name of the properties doesn’t matter, which is when I got the “a-ha!” moment.
So let’s say I have a view called MyView with two properties, name and description. On the other side, I have two model objects. The first model object is a User object with properties fullname and title. The second model object is a Project object with properties title and description. So to wire the view with the User object we get the following:
And to bind the view with the Project object we get the following:
So based on the above two examples, it becomes clear that the view’s properties and the model’s properties do not have to be called the same thing. Hazzuh! Although if the properties do happen to be called the same thing then that’s fine too. In fact, the example extends to all bindings in general.
Now, the code examples above do raise some other questions. First, you may notice there’s no reference to User object or a Project object. Rather, the bindings seem to be using these controller thingies called “userController” and “projController”. Turns out that it is good practice to not allow views to directly connect to a model object, but, rather, that the view connects to a controller object that acts as a proxy to the model object. The controller decouples the view and the model object. Okay, cool. So you have to create these controller objects. No sweat.
The other thing that may seem weird in the binding examples is the string that looks like some kind of path, such as ‘myApp.userController.fullname’. This is called a property path. SproutCore has this handy feature of looking at an object graph and traversing it to get to a object’s given property. The path can be either relative or absolute. In this case, the example shows an absolute path where the ‘myApp’ object is the root of the graph. Cool. Makes coding easier.
Finally, what’s the deal with the xxxBinding, where the “Binding” is a suffix to the property named “xxx”? When creating a new instance of a view, there is logic that will check for these specially named properties that get added to the view. When found, SproutCore will then auto-magically create the real binding mechanisms that connects the view’s property xxx with the model’s property… er, in this case the controller’s property acting as a proxy to the underlying model.
Anyway, this helped clear up some of the confusion I had. I’ve included a picture to show visually what is going on.