This post is part of the “ITworks Design Journal” series.

After deciding on a language and framework for the new inventory/work order application, I started to write some code. I wrote a couple of samples just to get the hang of the widgets and how handlers worked and all that jazz. Before long, I sat down to begin the application proper.

It didn’t take long to realize that something didn’t feel right. My default Application implements EntryPoint object was building my UI, creating the login dialog box, and a bunch of other stuff. I tried to use classes to separate it as much as possible, but it just wasn’t working out like I wanted.

Then, I discovered an overview of the GXT MVC classes, guided by the sample Mail application that comes with GXT. I didn’t even know that GXT had a set of MVC classes. After reading over the tutorial, I set to work rebuilding the application using a MVC pattern.

For the uninitiated, MVC stands for "Model View Controller" and is a way of organizing your code into classes that have specific roles¹:

• Models are domain-specific representations of information. Logic attached to your model gives meaning to the raw data it contains.
• Views render the model in a form suitable for interaction (in this case, the rich web UI). A single model may have multiple views for different purposes. Views are responsible for capturing user interaction.
• Controllers are responsible for the business logic–they process commands and events and indirectly make changes to the model.

In GXT, there is a Dispatcher singleton that is used to dispatch events to controllers, which can register themselves to certain event types. Application control is handled by firing events which are handled by controllers, which in turn process business logic, update models, and finally pass events on to the view which then updates the UI and waits for the user to interact with the application in some way.

Using this design pattern really increased code readability and made it much easier to organize my thoughts.

• (Root) The application starts by creating the controllers and firing the "Init" event using the Dispatcher.
  • (AppController) The controller for the application, AppController, receives the "Init" event
  • (AppController) The application controller creates its view and asks the Dispatcher to fire the "Login" event.
• (Root) The Dispatcher fires the "Login" event.
  • (LoginController) The login controller receives the event and initializes its view.
    • (LoginView) The login view creates its model (a "User") and its UI (LoginDialog) and waits for the user to entier their credentials.
    • (LoginView) The view captures the user’s input and asks the model to authenticate. If successful, the view hides the dialog box and asks the Dispatcher to fire the "BuildUI" event, signalling that the next phase of the application should start.
• (Root) The Dispatcher fires the "BuildUI" event.
  • (AppController) The application controller also processes this event and simply passes it to its view (nothing to do on the business logic side).
    • (AppView) The application’s view builds the basic UI.

And so forth and so on. This pattern allows you to keep every piece of the application completely separate, and still provides a way to communicate between them (via the Dispatcher) if necessary.

¹ http://en.wikipedia.org/wiki/Model–view–controller