With that said lets talk about this nifty trick shall we? First and foremost if you have not read Evin’s post about the “Root Controller Paradigm” click here, I will wait…

Ok now that you have that out of the way, let’s say that I am using this technique to build up a tree of objects to display in a source list. While I am building this tree I decide that I want to have some dynamically calculated value appended to the the end of the text in the collapsible header row. A good example would be a list of tasks and the header row’s text displays as the name of the task list. The dynamically calculated value would be based on the number of tasks, the effort each task will take, and it’s priority. The purpose of this value would be to display an estimated time-to-completion for this task list.

To do this you need to know when the effort and priority properties change on each task in this particular list ( the length of the list is already being observed for you because it is the content array of the controller ). Right at this moment you start trying to figure out how to observe these properties on each task in the list ( the content array of your controller building this tree of objects ). You might try adding the following method to your controller as I did.

someMethodName: function(){
/*
do something to recreate the tree
of objects to update the display
*/
}.observes('[]*effort')

You say on with the solution, well I’m here to tell you that the solution is fairly straight forward once you step back for a second to think about what you really want to do here. And now for the solution: We know that every item in the content array inherits from SC.Object ( if the objects are created using some construct bundled with sproutcore ). Because of this they also have the observable mixin applied and with this knowledge we have all of the tools we need to make this happen.

In your controller you have a method that builds each object in the tree of objects for your source list. In this method you have access to the the task list object and it’s array of tasks and their properties. This is how you are providing your header row text and calculated value. The observable mixin gives us the methods we need, “addObserver”, “removeObserver”, and “hasObserverFor”. With these methods we can now add observers to the effort and priority properties that will fire a method when they are changed and cause the tree to be rebuilt and the UI will display the result immediately. Here is the code:

for (var i = 0; i < len; i++){
task = tasks.objectAt(i);
// Removed usage of hasObserverFor via Charles' Comments
task.removeObserver('effort',this,'_contentHasChanged');
task.removeObserver('priority',this,'_contentHasChanged');
task.addObserver('effort',this,'_contentHasChanged');
task.addObserver('priority',this,'_contentHasChanged');
effortString = task.get('effort');
if(effortString &&
task.get('priority') !== CoreTasks.TASK_PRIORITY_LOW) {
// sum up effort for High/Medium priority tasks
effortMin = parseInt(effortString, 10);
var idx = effortString.indexOf('-'); // see if effort is a range
if(idx === -1) { // not a range
effortMax = effortMin;
} else {
// effort IS a range, extract max
effortMax = parseInt(effortString.slice(idx+1), 10);
}
totalEffortMin += effortMin;
totalEffortMax += effortMax;
}
}
if(totalEffortMin !== 0) {
var totalEffort = '' + totalEffortMin;
if (totalEffortMax !== totalEffortMin) {
totalEffort += '-' + totalEffortMax;
}
displayName = displayName + ' {' + totalEffort + '}';
}
return SC.Object.create({
displayName: displayName,
assignee: assigneeObj.assignee,
treeItemChildren: tasks,
treeItemIsExpanded: YES
});

Hopefully this will help you on your way and point you in the right direction. Just remember this, when you think you’ve hit a wall look to the comments and the code in sproutcore’s source and you will probably find the answer. If by some chance you are not able to find the answer there you can always look to this blog, as I will post any way that I find to get the most out of the sproutcore frame work. Don’t forget to drop into the #sproutcore IRC channel on irc.freenode.net.

What is the “Delegate Design Pattern” ?

Let’s talk about the meaning of a delegate. In languages such as C#, Java, etc… you usually think of a delegate as nothing more than a function pointer. In languages such as Objective-C, javascript, ruby, etc… you can think of a delegate as an instance of a class (an object) to which work is delegated. It may or may not be obvious how powerful this concept is, so I’ll give an example:

In most applications you will inevitably need to display a list of data. There are several approaches to get the data into the list. You could use straight data binding and cram all of the data into your view ( inefficient ) and let the view deal with pagination and so on, or you can use a delegate with data binding. The use of a delegate will allow the view to just worry about displaying data and it decouples the view from the model. In this case the delegate and the controller ( sometimes the same object ) work together to provide the data that the list needs at any given time.

Given a list in this fashion you can set up the view so that all it cares about is it’s size and that it is displaying a “name property”.  The List can then ask the controller for the data it needs and only the data it needs based on it’s size. The controller will then [call | invoke] a method on the delegate to calculate the number of records that can be displayed in the area of the list, then it returns this number of records to the controller and the controller will give this to the list(view) and it gets displayed.

There are at least two distinct advantages that I can think of here:

1. In straight data binding it becomes too easy to tie your view down to just one specific model.
2. In straight data binding your controller will stuff all of the result-set (RecordArray) down the list’s throat and expect the list to be ok with it, not choke and spew. What I’m trying to get at here is that this can really be inefficient.

Well that’s it for my humble explanation of the delegate design pattern, In the next post I will expand on my example of a list view and show you how this pattern is used in sproutcore’s CollectionView.

Now, don’t get me wrong here I don’t mind the extra work to spruce up a tumble-log, but the concept of tumblr doesn’t really foster the longer post model, so for now I’ll avoid the extra work and use WP’s built-ins.

Do check back within the next day or so, I will have my technical posts here as well as some new material on #sproutcore and Google App Engine.