PDA

View Full Version : Controller actions vs. View events



tachtevrenidis
20 Apr 2012, 10:18 AM
Can somebody shed some light on the runtime differences between a controller action and a view event. Examples of when to use one over the other are welcome. Mainly what I am interested in, is how performance is impacted. Best practices are also welcome.

By the way, I have already read this (from the docs):


If you're used to using Ext Designer, where instead of using controllers you added event handlers to your UI components, you can still work that way. In fact, adding events to views may be the right approach if you are only adding actions to one view or a small number of them. Architect makes that easy, since events can be added from within Architect using the Event config. With a view component selected in the Inspector, go to Events in Config and click the add button -- the plus sign ("+") on the right. Open a scrolling list of events by clicking the arrow next to the field that opens and select an event.

The potential limitation of events is that they can be a higher overhead way of adding actions to an application. Events "tell" other parts of an application to do something, so you have to attach the code for the event to any component that wants to drive a particular action. If that is limited to a component or two, that doesn't take you too much time when you program or slow your code when it runs. But if you have to do that over and over again to many components, that makes a lot of work for you, potentially slows app performance, and creates a maintenance challenge for others who have to update the app later.

Just to be clear, a controller action would look like this (function omitted):



control: {
"somethingList": {
itemtap: 'onListItemTap'
}
}


while an view event would look like this:



listeners: [
{
fn: 'onMenuListItemTap',
event: 'itemtap',
delegate: '#menuList'
}
]

mitchellsimoens
23 Apr 2012, 6:54 AM
This is a loaded question with many answers due to many scenarios.

Short answer for what I do is all logic needs to be in the controller. Views can have some logic if dealing with elements (I fire an event on the component in a listener on the element). Another reason why views can have some logic is (depending on your MVC definition) the controller shouldn't have too much knowledge of the view structure. So if a form has fields, the controller shouldn't know this and the form can have a listener the fields and fire it's own custom event on the form to normalize the event.