We have the fuel for our application; the data will bring life to the coding engine we're about to build. We now need to establish controllers that will constitute this engine and views that will give us a user interface to control and visualize it. Consider the following screenshot:

For the outer area marked as 1, we have a main view that provides a container for other views. This will have a corresponding view controller that will manage any cross-application concerns from the main's subcomponents.

For the inner section marked as 2, we have the dashboard view, a container for four charts. Its view controller will manage the live updates of the top two charts.

Each subpage will add an additional view (see 3), for example, a Web view and an associated view controller. It will present and control the historical log chart, the statistics grid, and user input to the filtering date fields and button, as shown here:

Here's how all our classes interact:

We've got the general picture of our application classes. Let's drill down and look at the details of each class in turn:

Instrumatics.view.main.Main: extends Ext.tab.Panel
- items[]
    - dashboard: extends Ext.panel.Panel
    - web: extends Instrumatics.view.web.Web
    - sql: extends Instrumatics.view.sql.Sql

The main view is a tab panel that contains all subpages:

Instrumatics.view.main.MainController: extends
Ext.app.ViewController
- onTabChange
- onNavigate

As we mentioned, the main controller deals with things that concern the whole application. It's responsible for swapping between the dashboard and subpages onTabChange and decides what action to take if the URL changes onNavigate. Four instances of Ext.chart.CartesianChart to display the various line charts that we need on the dashboard, as shown here:

Instrumatics.view.dashboard.Dashboard: extends Ext.panel.Panel
- items[]
- live-sql-requests: extends Ext.chart.CartesianChart
- live-web-requests: extends Ext.chart.CartesianChart
- historical-sql-requests: extends Ext.chart.CartesianChart
- historical-web-requests: extends Ext.chart.CartesianChart

We need some code to set up our live-updating charts, so we do this in initializeChartRefresh:

Instrumatics.view.dashboard.DashboardController: extends
Ext.app.ViewController
- initializeChartRefresh

The Ext.app.ViewModel is as follows:

Instrumatics.view.dashboard.DashboardModel: extends Ext.app.ViewModel
- store.webLogs
- store.sqlLogs
- store.historicalWebLogs
- store.historicalSqlLogs

The view model for the dashboard sets out four separate sources of data, one for each of the charts:

Instrumatics.view.web.Web: extends Ext.panel.Panel
- filters: extends Ext.Container
- historical-web-requests: extends Ext.chart.CartesianChart
- statistics-grid: extends Ext.grid.Panel

The associated view controller is as follows:

Instrumatics.view.web.WebController: extends Ext.app.ViewController

Ah! This is a pretty sparse view controller for a view, which is actually doing quite a lot. Let's look at the view model and things might become a bit clearer:

Instrumatics.view.web.WebModel: extends Ext.app.ViewModel
- stores
    - logData
    - logStatistics
    - categories
- data
    - currentCategory
    - currentStartDate
    - currentEndDate

The plan is to pull the historical log data and the statistics about this log data from a couple of stores. We'll have another that holds the categories that the user can use to filter the grid view.

The key part of this view model comes when we think about the current state of the application. For this subpage, it'll be stored in the currentCategory, currentStartDate, and currentEndDate variables.

As we're keeping all of the state in the view model, we can bind to the UI controls that set this state and in turn bind these values to a store filter. This means that changing the value using the UI will automatically change the filter value without requiring any glue code in the controller.

This implementation requires a strong understanding of the power of view models and a thoughtful eye for the design of the application. We'll go into detail on this later when we write the code for this section.

The last part of the application is the SQL subpage. This is essentially the same as the web subpage, but displaying a different set of information, so we won't go into detail about its design.