How MVC controllers are used in an Extjs application

Question

I am new to Extjs, and after going through several tutorials and blogs on the Extjs MVC template, I don’t understand how a complex application (for example, 10-15 page navigation) can be built on the extjs platform.

The sencha forums suggest that all controllers should be defined in advance in app.js (since load controllers will not get any performance issues before the distribution, compared to the user interface that loads the DOM. Please note that this was mentioned by the sencha forum manager).

Following the approach above, I have a few questions:

• when does the controller get an instance? Are they all downloaded and installed when the application loads and continues to listen to the events defined in them, until the life of the application?

• What does the definition of the [], Stores [], and Views [] models in the controller class mean? When are they loaded and instantiated?

• How does moving pages with controllers work? If the transition to a new page is simply translated into getParentContainer.remove (componentX) and getParentContainer.add (componentY), then the purpose of the controllers is just a file for processing events?

• Is there any area (destruction of objects) with controllers? If not, how can I create and destroy multiple instances so that my actions are not listened to by the wrong instance (I saw that some blogs that mention controllers are mostly singleton)?

Can someone please shed light on this? Any examples / illustrations would be very helpful.

thanks

Answer 1

In Ext JS, the Ext.app.Controller classes (out of the box) created with application initialization. In fact, the controller init () is called before running () the application itself. So yes, the controllers are "lifelong", listening from the moment the application is launched throughout the life of the application. There are ways to dynamically create and destroy controllers, but this will require a special implementation.

Ext JS 5, however, introduced the concept of ViewController. It extends the same base (Ext.app.BaseController) as Ext.app.Controller, but unlike above, the ViewController is created and destroyed along with the instance of the view to which it is attached. This is automatically handled by the framework - no special implementation is needed to make this work.

As for the models: [], stores: [] and views: [], this basically requires () for the controller, instructing it to ensure the loading of these classes. Conventions are just a shorthand way to require these classes from their specific namespaces (e.g. AppName.view, AppName.store, etc.). In the case of views and repositories, this convention will also generate getters for the required classes.

As for navigation, it is up to you. There are several ways to create an Ext JS application. You can make a one-page application in which navigation is likely to resemble what you mentioned, pretty close (a lot from me). You can also create multi-page applications that can provide a more traditional perception of the page on the page, but use common code and classes for each page, depending on the needs of each page.

Finally, regarding the listener collision issue, the answer is “it depends.” If you use Ext JS 4, you only have “lifer” controllers, and therefore avoiding collisions in listeners is a matter of being extremely knowledgeable about the selectors that you use in your listen () or control () sections, and ensuring that you don’t duplicate listeners (either through explicit duplication or too much choice) if that’s not what you want to do. However, with Ext JS 5, the ViewController concept more or less eliminates this problem because the ViewController “listening” domain is limited to the instance of the view to which it is bound.

As for the examples, I definitely recommend starting 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 “new” documentation has a really great discussion on architecture, which goes deeper into the details of these concepts than is possible on SO.