Controllers act as a central place to handle the events originating from various views. It helps us to take care of the cross-view interactions to build the application flow.
In the Ext JS framework, a controller does the following:
Ext.util.Observable
mixin which acts as the foundation for raising events and registering handlers for the events.model
, store
, and view
.ref
objects.ref
config, if references are to be cached (default behavior, unless forceCreate
is set to true
). If the component is not cached and autoCreate
is set to true
on the ref
object, then the component is created and added to the cache.In the Touch framework, a controller does the following:
Ext.util.Observable
mixin.ref
objects.ref
config. If the component is not cached and autoCreate
is set to true
on the ref
object, then the component is created and added to the cache.The previous list highlights the differences in the controller implementation on two frameworks. Though the effort is on to implement a consistent interface and behavior across the two frameworks, there are still differences that need to be addressed.
Profile is applicable only to Sencha Touch and it helps us to build the application which can work on multiple devices. A profile must be created for every device where we handle the device specific layouts and behaviors.
Every profile must extend the Ext.app.Profile
class and must implement the isActive
method. During the application's initialization, the framework goes through all the profiles mentioned in the profiles
config on the Ext.application
class and executes their isActive
method, one-by-one. The first profile for which the isActive
method returns true
is considered as an active profile. A profile-specific controller, model, view, and store needs to be set on the profile class using the controllers
, models
, views
, and stores
properties. Let us see what changes we will have to make to our touchapp
to support profiles.
Say, we are going to support two profiles—Desktop
and Phone
. All the behavior that we built in the previous chapter needs to be there for the Desktop
profile. For Phone
, we would have a different layout. The following are the steps that we would have to go through to make use of a profile:
profile
folder under the app
folder.Desktop
profile class and save the following code inside the Desktop.js
file inside the profile
folder:Ext.define('AM.profile.Desktop', { extend: 'Ext.app.Profile', config: { controllers: ['Users', 'Departments'], views: ['user.List', 'department.List'], stores: ['AM.store.Users', 'AM.store.Departments'], models: ['AM.model.User', 'AM.model.Department'] }, isActive: function() { return Ext.os.is.Desktop; }, launch: function() { var config = { layout: 'fit', items: [{ xtype: 'departmentlist', docked: 'left', width: 400 }, { xtype: 'userlist' }] }; Ext.Viewport.add(config); } });
Phone
and keep the following code inside Phone.js
in the profile
folder:Ext.define('AM.profile.Phone', { extend: 'Ext.app.Profile', isActive: function() { return false; //We do not support Phone...so always return false } });
app.js
with the following code:Ext.application({ name: 'AM', profiles: ['Desktop', 'Phone'] });
desktop
folder under the controller
and view
folders and move the controller JS files from appcontroller
to appcontrollerdesktop
and from the appview
to the appviewdesktop
folders.desktop
in their names. For example, AM.controller.Users
will change to AM.controller.desktop.Users
.After making all the changes, the folder structure should look as follows:
Run the application on your desktop browser and you will see the same output that we saw in the previous chapter. If the application is run on a phone, no view is rendered.
3.143.0.85