Pancake/2012-02-13 Drawer Titles

Bug: drawer contents is not updating https://bugzilla.mozilla.org/show_bug.cgi?id=726701.

Adding currentStack to the updates list fixes it. This means someone is subscribing to currentStack:change.

   selectStack: function(stack) {
     var update = this.dissectStackModel(stack);
     update.currentStack = stack;
     app.set(update, { silent: true });
     Bridge.prototype.selectStack.apply(this, arguments);
     app.navigate("stack/" + stack.id, true);
   },

This is the flow that is currently happening with the drawer. It is basically Dolphin MVP:

   Event in drawer view
    -> Notify controller via event
     -> update model
       -> Notify drawer view

A sort of twist: the view has a direct reference to the model and subscribes to its change: events.

We've changed this flow accordingly:

   Event in drawer view
    (Drawer view backed by stack model - no change)
    -> Notify controller
     -> Controller updates active state of app.
      

The stack contents drawer pane should be backed by the stack model. It represents a discreet set of data, not a state.

Currently, all stack lists are contained in a single view that is manipulated (by changing collection?). We should be spinning off separate views instead and using widget to replace the one displayed. This would also solve the "old stuff is showing up in the drawer" problem. It is also conceptually simpler for views to be a representation of a stated collection of data.

Yup, we've gone this route.

Controllers are objects but need a consistent functional interface (since functions are what Backbone.Router.prototype.route consumes). Currently drawer.app.js solves this problem differently every time, repeating controller exit and enter logic.

Page.prototype.activateController solves this problem by wrapping up controller switching details in a function. The first argument is the controller instance you want to switch to. Use it in conjunction with _.bind (Function.prototype.bind) to create curried route handlers. Alternatively, the first argument can be a function, in which case activateController will invoke it, giving it the context and parameters -- this is useful for lazy controller instantiation. Care should be taken to avoid using this as a second controller -- controller logic should live in the enter method instead.