Remove global var usage from controller .js files

[ccmitchellusa]

The controller .js files that correspond to the views should not have references to globals, for example todoApp that's referenced in many places (there are a few other application-wide objects and collections hanging off of that instance).

ViewControllers have a reference to their parent "App Controller" already, so we should at a minimum access these objects off of the app controller instance.

Helpers can/should be created by subclassing Application. See src.js, where the Application instance is created. Instead, create a TodoApplication class which extends Application and adds accessors for application-wide objects. The individual view controller's can then use the helpers directly to access these objects.

If these objects really don't need to be application-wide, and are used by a narrower set of view controllers, they can be associated with a parent controller that has access to the application itself, but scopes the variable access to a narrower set of view controller children. This help with reuse, rather than glomming a bunch of objs onto the app controller, they can be grouped/organized in larger apps.

[msmiths]

It might make sense to extend this idea to define more comprehensive interfaces for Application and View that allow components to be located programmatically. For example, you could define a getApplication() function on the View base class so that any view can easily obtain a reference to the top level Application object without needing to the name of the global. You also add explicit getParent() and getChildren() functions to the View base class as well... and maybe a getView(viewName) method to the Application class (this is complicated by the fact that the view ids are automatically generated by the framework so you still need some knowledge of the application structure).

[eric-wang]

current dojox.app.Controller is a global controller to control views and models, so each controller instance has a reference to the application object.
Maybe we can consider this in the next release.

[ccmitchellusa]

There are tablet scenarios/apps that would require multiple "app" controllers for different portions of the app, and I think that in some Desktop app scenarios we'll also need the ability to have multiple app controllers. An immediate example of this is in the Reminders iPad app, how it pops secondary tooltip windows and reuses the details view navigation within the views that are displayed in the tooltip dialog. There are other real iPad examples that do view navigation differently within secondary dialogs/popups vs. the rest of the app.

[cjolif]

just a thought: maybe we could also pass references that are needed as parameters to the various controller methods (init, beforeActivate..). Needs more thinking...

[eric-wang]

I don't call (init, beforeActive) as controller methods, they are view's lifecycle methods. Now controller know views, but view not know controllers because controller is global and controller all the view.
It's better to think store all the controllers in application instance and provide APIs to get the controllers if needed.

[cjolif]

@eric-wang when I said "controller" here I was using @ccmitchellusa terminology in which view is the template and the lifecycle/definition is the view controller.

[eric-wang]

ok, get it.

[cjolif]

work started in 16233f5 the other globals must be removed