Controllers are the glue that binds your application together; it's often useful to look at our wireframe again and break down the aspects that represent view classes and will need a controller to orchestrate their actions. The basic wireframe can be seen in the following screenshot:
The wireframe broken down: yellow, green, and blue are all identified as separate views
In this application, as we have a very straightforward layout and set of interactions between components, we can get away with a very simple architecture.
While it's important to create a strong starting structure in the early days of an application, you should always strive to build something that is clearly designed and doesn't contain classes that have been added just in case they are needed.
Tip
You Aren't Going To Need it (YAGNI) is a popular term with some software developers who believe that less is more—don't write code based on some far-future assumption about what you might need. Instead, iterate on your architecture with every addition and take as much care with these additions as you would at the start of a project.
In the Ext JS MVVM architecture, a top-level controller is used to mediate interactions between other controllers. Here, we've elected to create just one controller (a view controller called Main) that will coordinate all of the actions of the views within its namespace.
Let's take a look at how these new classes will look when working together and in association with our data layer:
The preceding diagram clearly shows how data flows through our application (from the data layer that interfaces with the client's API to controllers and then down to views via view models). We can now flesh out each of these classes by naming them and specifying their methods and properties:
ArchitectCms.view.main.MainController: extends Ext.app.ViewController - onAddClick - onDeleteClick - onSaveClick - onPageSelect ArchitectCms.view.main.PageModel: extends Ext.app.ViewModel - pages - currentPage - isUnsavedPage - searchTerm ArchitectCms.view.main.Main: extends Ext.panel.Panel ArchitectCms.view.main.Detail: extends Ext.form.Panel ArchitectCms.view.main.Tree: extends Ext.tree.Panel - searchFor
Let's break this down a bit and talk about the reasons we've designed the application in this way.
It's immediately clear that the controller is where most of the interesting stuff is happening, but it's important to remember to keep your controllers slim. If you find yourself with lots of methods in there, it's a good sign you need another controller—look for the logical place one might split off.
In our case, a future iteration of the application might have separate view controllers for the tree and for the detail panel with an overarching controller to enable communication between the two. For now though, we just don't need this. All we have in our MainController class is four methods that will handle actions from our views.
Tip
Controllers are there to support everything else. Focus on your data first, then your views, and use the controllers to connect them. As such, work out which events your views are going to fire and your controller will pretty much write itself—all it'll be doing is handling these events and passing off the hard work somewhere else.
This is a great opportunity to put implementation details to one side for a moment and think about how these classes would look if they were designed to make our life easy.
For example, the view model called PageModel has a method called isUnsavedPage, which allows you to ensure that the user doesn't navigate away before they save a new page, ensuring they won't lose any data.
Designing like this up front enables us to think about all of the great features that make for a good user experience without having to get worked up about the code that will make it happen. Of course, every situation is different. We need to make sure that we don't let our imagination run away with itself and start dreaming up features that aren't required!
There's a short discussion to be had with regard to the searchFor method on the Tree class. In controllers, we pull together a few parts of our application and hand off the real work to them, not to the controller itself. That's exactly what we're doing here. Think of this method in the same way you would use the expandPath method on the Ext.tree.Panel base—a method that acts on the tree interface without breaking out and interacting with anything else. Its logical place is as an augmentation to the tree UI.