Method Ext.app.Controller.getController() is deprecated (which was the right design decision, I think) and the documentation clearly suggests using this.getApplication().getController() instead (which is also the right thing, I believe; and it does come in handy sometimes!).

But Ext.app.Application.getController() is, indeed, marked as private now. Which, to me, contradicts with the suggestion above. Unless Sencha developers have some other plans on that part of Sencha Touch 2 architecture, I would ask to "release" Ext.app.Application.getController() to the public again (by removing the "private" tag from it).

mitchellsimoens

12 Oct 2012, 6:23 AM

Cross controller calling isn't 100% recommended. There are better ways to do this like using a utility method for code reuse or setup controller superclass and extend that controller to reuse that code.

VladimirTechMan

21 Oct 2012, 5:15 AM

Oops. I was on a business trip last week and somehow missed your reply to this thread, Mitchell...

Thanks for your comments. It's understood about Sencha developer's view on implementing controller interactions. The approach with super-classes looks reasonable to me. (Indeed, I think that mixins may be even better for that purpose -- from how I see it, at least.)

I would suggest that Sencha also reflects the preferred way for controller interactions in the Sencha Touch documentation at some point. The descriptions of Application.getController() and Controller.getController() may be a good place to add such a note. Also, a sentence or two on this topic in the general description of Controller would be nice to have. Thus let's re-qualify my request into one for a doc improvement. :)

shepsii

22 Oct 2012, 7:31 AM

I think the right way to do this is events using the application object as the bus, because then only an event name is shared and controllers do not need to know the exact name of methods on other controllers - or even depend on the existence of the other controllers. So this is how I do it. Would be nice for the application object to then be targetable in the control section of the controller config tho.

mitchellsimoens

22 Oct 2012, 7:40 AM

I think the right way to do this is events using the application object as the bus, because then only an event name is shared and controllers do not need to know the exact name of methods on other controllers - or even depend on the existence of the other controllers. So this is how I do it. Would be nice for the application object to then be targetable in the control section of the controller config tho.

Events are one way and a valid way, you can do it in init

init : function(app) {
var me = this;

app.on({
scope : me,
someevent : me.someFunc
});
}

The issue with events is they can affect performance if you are going to use them a lot. If you have an abstract controller this performance is not an issue as the methods are on the prototype of all subclasses

shepsii

22 Oct 2012, 7:43 AM

Good point about performance, Mitchell.

I add the listeners on the init method already - I'd prefer to do it something like this:

config: {
control: {
application: {
event: 'method'
}
}
}

mitchellsimoens

22 Oct 2012, 7:50 AM

And I like the elegance of something like that but the control config uses xtypes to resolve the selector in this case would be application.

One would argue that we could use application as a special keyword which would be valid but it would add to confusion especially if someone wants to use application as an xtype or ref.