How are Controllers used with MVC in Extjs application

Question

I am quite new to Extjs and after going through some tutorials and blogs on Extjs MVC pattern, I am not clear as to how a complex app(say 10 - 15 page navigation) can be built on extjs platform.

From the sencha forums, it is suggested that all controllers need to be defined upfront in the app.js(because loading controllers before hand will not be a performance hit as compared to UI which loads DOM. Note that this was mentioned by a sencha forum manager).

Going by above approach, i have few questions:

• when does a controller get instantiated ? Are they all loaded and instatiated when app loads and keep listening to events defined in them till lifetime of the app ?

• What does defining Models[], Stores[] and Views[] within a controller class mean ? When do they get loaded and instantiated ?

• How does navigation of pages work with controllers ? If navigation to a new page just translates to getParentContainer.remove(componentX) and getParentContainer.add(componentY), then the purpose of controllers is merely a file to handle events ?

• Is there any scope (instantiation > destruction) with controllers ? If not how can multiple instances be created and destroyed so that my actions are not being listened to by wrong instance (i have seen some blogs that mention controllers are mostly singleton) ?

Can someone please throw some light on this ? Any examples / illustrations would be of great help.

Thanks

Answer 1

In Ext JS, Ext.app.Controller classes are (out of the box) instantiated with the initialization of the application. In fact, the init() of the controller is called before the launch() of the application itself. So yes, controllers are "lifers", listening from the moment the app starts throughout the lifetime of the application. There are ways of dynamically creating and destroying controllers, but this would require a custom implementation.

In Ext JS 5, however, the concept of the ViewController was introduced. It extends the same base (Ext.app.BaseController) as Ext.app.Controller does, but unlike above, the ViewController is created and destroyed along with the view instance to which it is bound. This is handled automatically by the framework--no need for a custom implementation in order for that to work.

Regarding models: [], stores: [], and views: [], these are basically requires() for the controller, instructing it to ensure that these classes are loaded. The conventions are simply a shorthand way of requiring these classes from their particular namespaces (e.g., AppName.view, AppName.store, etc.). In the case of views and stores, this convention will also generate getters for the required classes.

Regarding navigation, that is up to you. There are a number of ways you can create your Ext JS app. You could do the "single-page" app where the navigation would probably resemble what you mentioned pretty closely (alot of mine do). You can also create multi-page apps which can deliver the more traditional page-to-page feel of a website, but leverage common code and classes for each page, depending on the needs of each page.

Finally, regarding the question of listener collisions, the answer is "it depends". If you're using Ext JS 4, you only have the "lifer" controllers, and so avoiding the collisions in listeners is a matter of being extremely cognizant of the selectors that you are using in your listen() or control() sections and ensuring that you are not duplicating listeners (either through explicit duplication, or too broad of a selector) unless that is what you want to do. With Ext JS 5, however, the ViewController concept more or less eliminates this concern as the ViewController's domain of "listening" is constrained to the instance of the view to which it is bound.

As far as examples, I would definitely encourage you to start with the documentation for Ext JS 5:

http://docs.sencha.com/extjs/5.0/whats_new/5.0/whats_new.html

http://docs.sencha.com/extjs/5.0.1/

The "what's new" documentation has some really great Architecture discussion which dive into the details of these concepts a lot more than is feasible on SO.