Why Sencha MVC architecture

Now that we understand the need of having MVC architecture on the client side, let us see why the Sencha MVC architecture was introduced as part of the Sencha Ext JS and Touch frameworks.

Let us look at the following code, written using Ext JS, which shows the list of users (from a users.json file) and shows an Edit User window with a form, populated with the selected record detail, when an entry in the list is double-clicked:

Ext.onReady(function() {
  
  //Define the user model
  Ext.define('User', {
    extend : 'Ext.data.Model',
    fields : [ 'id', 'name', 'email'],
  });

  //Define the Users store, which uses the User as the model 
  //and loads models from the users.json file
  Ext.define('Users', {
    extend : 'Ext.data.Store',
    model : 'User',
    autoLoad : true,	//load the data into the store as soon as it is initialized

    //proxy configuration, which is used to load the data
    proxy : {
      type : 'ajax',
      api : {
        read : 'data/users.json'
      },
      reader : {
        type : 'json',
        root : 'users',
        successProperty : 'success'
      }
    }
  });

  //Create an instance of the store that we defined above
  var store = Ext.create('Users', {});

  //Create the viewport which shows a grid loaded with the
  //user information from the store
  Ext.create('Ext.container.Viewport', {
    items : [ {
      xtype : 'grid',
      title : 'All Users',
      store : store,
      columns : [ {
        header : 'Name',
        dataIndex : 'name',
        flex : 1
      }, {
        header : 'Email',
        dataIndex : 'email',
        flex : 1
      } ],
      //event handlers
      listeners : {
        itemdblclick : function(view, record) {
          
          //Create a window and show a form panel with the values
          //populated from the record
          var win = Ext.create('Ext.window.Window', {
            title : 'Edit User',
            layout: 'fit',
            autoShow: true,
            height: 120,
            width: 280,
            items: [{
               xtype: 'form',
               padding: '5 5 0 5',
               border: false,
               style: 'background-color: #fff;',
               items: [
                 {
                   xtype: 'textfield',
                   name : 'name',
                   fieldLabel: 'Name'
                 },
                 {
                   xtype: 'textfield',
                   name : 'email',
                   fieldLabel: 'Email'
                 }
               ]
             }],
             buttons: [{
                 text: 'Save',
                 action: 'save',
                 handler: function() {
                   alert('Save!'),
                 }
               },
               {
                 text: 'Cancel',
                 action: 'cancel',
                 handler: function() {
                	 alert('Cancel!'),
                 }
            }]
          });
          
          win.show();
          win.down('form').loadRecord(record);
        }
      }
    } ]
  });

});

The example uses a users.json file, which has the following content:

{
  success: true,
  users: [
    {id: 1, name: 'Sunil',  email: '[email protected]'},
    {id: 2, name: 'Sujit', email: '[email protected]'},
    {id: 3, name: 'Alok', email: '[email protected]'},
    {id: 4, name: 'Pradeep', email: '[email protected]'},
    {id: 5, name: 'Ajit', email: '[email protected]'}
  ]
}

Ext.onReady acts as the entry point to the application and is called as soon as the Ext JS framework is loaded and initialized. In the previous code, the complete application logic is written inside a single file, say, app.js. To run the code, we would create an index.html with the following content:

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title id="page-title">Account Manager</title>

  <link rel="stylesheet" type="text/css" href="<extjs folder>/resources/css/ext-all.css">
  <script type="text/javascript" src="<extjs folder>/ext-all-debug.js"></script>
  
  <script type="text/javascript" src="app.js"></script>
</head>
<body>

</body>
</html>

Replace <extjs folder> with the folder on your system where Ext JS 4 distribution was extracted. In my case, I kept it inside the ch01 folder. The following screenshot shows what the project structure will look like after all the files are created:

Why Sencha MVC architecture

Publish and Start the server and access the http://<host>:<port>/SenchaArchitectureBook/ch01/index.html URL from your browser. You will see the users' list and when you double-click on an entry, you will see the output as shown in the following screenshot:

Why Sencha MVC architecture

Now, let us review the code and understand, though it is a functional code and meets the requirement, why it is considered to be a bad application. There can be multiple ways to model this application with a varied number of files making use of the various object-oriented principles. However, I have presented the worst (well, still not "the worst") way to code the application to help us understand the demerits and then see how each one of them can be addressed by sticking to a well-defined architecture. In the previous code, we first defined a User model with their fields, which is used by the store to represent the data in memory. Then we defined a Users store, linking the User model with it. In the store, we specified the proxy information, which the store would use to load the data from the mentioned URL, data/users.json. We then created a viewport to which we added a grid panel, xtype: 'grid'. This grid panel uses the instance of the Users store that we created using var store = Ext.create('Users', {});. The grid shows two columns, Name and Email. We also registered the handler for the itemdblclick event on the grid panel. The handler code creates a window with a form panel inside it and two buttons, Save and Cancel. We registered the dummy handlers for the Save and Cancel buttons, which show an alert message when the user clicks on them. We then show the window to the user and load the form inside it with the model that we had received from the framework as the second parameter to the itemdblclick handler.

If we look more closely, the following issues are evident in the previous way of coding the application:

  1. If the grid has to be replaced with a different view component, say, a DataView component, the complete app.js code needs to be changed. For that matter, if any change is made to the view, model logic, and controller logic, then the app.js file needs to be modified, which makes the parallel development unmanageable in bigger projects.
  2. Reusability of the view is not possible. Also, reusability of the model and controller logic is questionable.
  3. Any change adds considerable testing effort as the testability of the code is really low. For example, if we choose to replace the grid with a data view component, then the complete code needs to be tested as the view logic is not separate from the controller.
  4. A person working on this project will only understand the project structure, how the code flows, and where what is written, and it takes a lot of training and documentation to make a newcomer (to the project) understand the project and the code even though the person has the technical skill. A person working on this project will have the same challenge if he/she has to move to a different Ext JS/Touch project in the organization.
  5. As the code structure does not follow any architectural guideline and best practices, for every project, a custom build process has to be developed and implemented for the build and packaging.

Until Ext JS 3.x, there was no MVC architecture. However, it was realized that given the rich functionality the framework offers, it was easy for people to divert from the best practices in a typical application development and introduce the problems that we outlined previously. The need was felt to have functionality in the framework, which enforces MVC architecture when it comes to application modeling and development. The benefits include the following:

  • As long as the applications follow the architecture, they work the same way, and hence it becomes a lot easier for anyone who knows one application, to understand and follow all the applications following the same architecture.
  • Sharing the code (view, controller logic, model and so on) across the applications becomes easier as all the projects follow the same folder structure, naming convention, and design, and hence a view written for one application can be used in another application.
  • Making the changes becomes a lot more manageable and reduces the overall testing effort considerably.
  • The Sencha MVC architecture uses class loading internally, which saves us from including all the JS files in the index.html and managing their orders manually. This comes as a great benefit to a medium to large application as there may be tens or hundreds of files.
  • We can use Ext JS build tools to create standard and optimized versions of your applications for production use.

In the next chapter, we will look at modeling the same application (or a slightly enhanced one) using the Sencha MVC architecture.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.163.13