Automatically `bindContext` on views

[creynders]

Since now we're taking control of views anyway, wouldn't it make sense to call bindContext in the wrapped view constructor?

[geekdave]

I'd like to revisit the role of bindContext, and maybe deprecate it so we can remove it soon. In the past it served two purposes: 1) Setting the context on the root view (no longer needed, since with DI nobody needs a concrete handle to the context anymore) 2) Setting a close listener on the view, to automatically destroy the Context and unbind its events when the view is closed (still needed)

We still need the 2nd behavior, but it should only happen with "root-level" views, not sub-views that share the same context.

To facilitate this, maybe we should change the way that Context objects are initialized, and require the root view to be passed to the Context constructor function. If we also want anyone having a concrete reference to the Context, we could also wrap the constructor in a factory function like:

// FooView.js

initialize: function() { 
  Geppetto.createContext({
    context: FooContext,
    view: this
  });
}

This would "bootstrap" the root view. Geppetto, behind the scenes, would instantiate a new version of this Context, and inject any of the View's dependencies, while concealing the direct reference to the context (we would no longer set a context reference on the view itself). Geppetto would still set a close listener on the view so that listeners/singletons would be cleaned up when the view is closed.

[geekdave]

I'm pushing a change that does the following:

Only set a context reference on "legacy" root-level views (that is, views that do not declare a wiring mapping and therefore do not support the new dependency injection API). This means that newer components that use DI cannot manually muck with the context object since they won't have a handle to it. A future version of Geppetto will remove this conditional setting of the Context in favor of using DI.

To address the original subject of this issue, there is already support in the mapView API to automatically inject views with their dependencies and listen/dispatch communication methods before their initialize method is called. See the _wrapConstructor method for implementation of this.