In Ext JS 4, we have the MVC pattern to build and clean well-structured applications. Looking back at our past few practical chapters, though, it seems difficult to imagine going back to MVC from the MVVM architecture that Ext JS gives us because, in each example, we've used view models to great effect to provide a logical way for data to flow through our application.
The interesting thing about these examples is how little code we write in many situations. Analyzing the application requirements and spiking a few tricky areas leads to writing a small amount of configuration of UI, controllers, view models, and so on. Ext JS automatically builds the plumbing through which our data can flow.
It's another example of why application architecture is so important, particularly when combined with a strong understanding of the tools at hand. It would be very easy for a naïve developer to jump in and start writing code to manually handle movement of data from an API through to the user interface using Ext.Ajax rather than models and proxies and manually loading data into components. However, by taking a patient and methodical approach, we can build a conceptual overview of the application that easily slots into the framework provided by Ext JS. By thinking about things upfront, we're making our lives much simpler for later use.
To this end, let's think about the controllers and views we'll need in this application.
What's the purpose of a controller? As you learned in Chapter 2, MVC and MVVM, it's to act as the glue between other parts of the application, and in the majority of cases, this is manifested in code that handles events. From UI clicks to routing events, the controller consumes them and passes off the real work to another class.
What does this mean for the way we think about architecture? It means that any action or event in the application will likely need an associated controller. If these actions can be bundled into a distinct grouping, then this could be an indication they warrant their own controller. With this in mind, let's look at our shopping application again:
What elements of the page could raise an event? A click on a category in the blue left-hand pane, so alongside the category list view, we'll have a category view controller as follows:
Alcohology.view.categories.CategoriesController: extends Ext.app.ViewController - onItemClick
Clicking on a product in the product list is an action we need to handle, so we'll have a product list view and a product view controller as follows:
Alcohology.view.product.ProductController: extends Ext.app.ViewController - onSortSelect - onCategoryRoute - onProductRoute - onProductClick - onProductClose - onAddToCart
Next up, the two icons at the top-right corner of the window need to trigger UI changes, so they need a view controller. Do we want a "header" controller to handle the events from the cart and account icons or can we use a "main" controller? It's one of these things that can boil down to a matter of preference; here, we'll use the main controller just to keep the number of classes from getting out of hand:
Alcohology.view.main.MainController: extends Ext.app.ViewController - onLoginRequired - onCartClick - onAccountClick - onAccountRoute - onCartRoute
Let's look back at our other UI wireframes. There are three remaining UI components and they're all modal windows. Firstly, the product detail window (interactions with this will be handled by the product controller that we've already identified).
Next is the shopping cart window, which will be paired with a controller that handles the user's interactions with the various buttons on the cart:
Alcohology.view.cart.CartController: extends Ext.app.ViewController - onCartClose - onOrderNow
Finally, the account window with its account view controller to handle login and registration is shown in the following code:
Alcohology.view.account.AccountController: extends Ext.app.ViewController - onAccountClose - onLoginRegister
There's a final place that will raise events that our application will need to handle. The requirements for this project stipulate that we implement routing to allow product pages to be shared via e-mail or social media. To meet this need, we'll have a controller specify the routes' definitions and matching handlers. The exact controller to take this role will depend on the nature of the route definitions, for example, if it's a route related to products, then the product controller will handle it. You can see a few of these route handling methods dotted around the controller designs in the preceding section.
Grouping actions and events in this way will often make the choice of which controllers to build an easy one, particularly when used in association with wireframes that allow you to look at the corresponding UI views.