View Full Version : Sencha Touch MVC Best Practices?

buffalo billion
15 Jun 2011, 6:19 AM
I apologize for the cross-post. I'm trying to wrap my mind around the MVC framework of Sencha Touch, but I'm finding a couple of different approaches. In one by Tommy Maintz, found here (http://vimeo.com/17705448), there is an approach to structuring Sencha Touch apps presented at SenchaCon 2010. It has the added weight of being by a Sencha Touch employee, but it is several months old. In other, more recent posts on Sencha Touch MVC, there are tutorials (such as here (http://www.sencha.com/learn/Tutorial%3aA_Sencha_Touch_MVC_application_with_PhoneGap), as well as Manning's MEAP Sencha Touch In Action by Jay Garcia) that seem to rely on Ext.Dispatch in the views to call specific controller methods, passing additional elements to the controller, which makes the views controller-aware.

My question is, which is considered the best practice to structure a Sench Touch MVC app?

21 Jun 2011, 10:37 PM

I prefer to have the views manage only the GUI part. I keep them as thin as possible.

I have the controllers manage the business logic. For me, the point you take as example (decide where to go after a given view / on a given user action) is business logic, so I put this in the controller.

It often requires a bit more typing - e.g; adding custom events to the view that the controller can listen to - but I find this cleaner. This way, you can for example reuse your view in another context, or embed it in another container if needed.


buffalo billion
22 Jun 2011, 6:27 AM
Thanks, Jean-Marie. I would agree with you. It seems that recent tutorials seem to favor the Ext.Dispatch in the views approach, though.

22 Jun 2011, 7:32 AM
I agree with @jmclem and our views are used to work with data (model) and fire events. Having a view that is coupled with a controller is bad practice IMO. Here are two scenarios that show why:

1. Say you have a view with a logout menu item. When you click the item you fire a logout event. Three controllers are listening for this event:
Header - to hide 'Welcome username'
Menu - to hide menu
App - send logout Ajax and show login screen

2. Say you have a dashboard that has three instances with different data of the same view:
Controller A creates view A and listens for events on that instance
Controller B creates view A and listens for events on that instance
Controller C creates view A and listens for events on that instance

#2 is probably more for desktop rather than mobile but still shows my point. To me, views and controllers knowing about each other is a circular dependency.

Another thing is with Ext JS 4 Ext.dispatch() went away. If Touch 2.0 is supposed to follow the Ext JS 4.0 MVC, then Ext.dispatch() will go away also.

buffalo billion
22 Jun 2011, 8:14 AM
@estesbubba, this makes sense to me. Could you maybe give a brief example of how/what you would replace the Ext.dispatch() call in the model with in the controller? How does the correct controller action know what to respond to? Also, would I need to include the mvc.js file to make it work?

22 Jun 2011, 9:08 AM
I've been working with Ext JS 4 so our Touch code isn't fresh in my head. I believe in our Touch code we use Ext.dispatch() between controllers but never in views. I don't know what the mvc.js is as I believe MVC is included in Touch. Here is a simple example (Ext JS 4 style but you get the idea) of how we use custom events in views and controllers listen for them.

Ext.define('MyView', {
extend: 'Ext.Component',

customEvents: [

initComponent: function() {
var me = this;


var config = {
items: [{
xtype: 'button',
handler: function() {

Ext.apply(me, config);

Ext.define('MyControler', {
extend: 'Ext.app.Controller',

init: function() {
var me = this;

me.view = Ext.create('MyView', {
data: me.data,
listeners: {
eventA: function() {},
eventB: function() {}

If you think about it, the base Touch widgets (buttons, checkboxes, etc) don't know anything about controllers. They just fire events and don't care if there are 5 listeners or 0. Your views should be the same. They don't care if they were created by a controller or another view - they just fire events and anyone listening can act. This way there is no coupling of your views to controllers.

buffalo billion
22 Jun 2011, 11:17 AM
Thanks much. This is great.