In Ext JS 4.2, the MVC event dispatcher was generalized with the introduction of event domains. These event domains intercepted events as they were fired and dispatched them to controllers controlled by selector matching. The “component” event domain had full component query selectors while the other domains had more limited selectors.
With Ext JS 5+, each ViewController creates an instance of a new type of event domain called the “view” event domain. This event domain allows ViewControllers to use the standard listen
and control
methods while limiting their scope implicitly to their view. It also adds a special selector to match the view itself:
Ext.define(‘MyApp.view.foo.FooController‘, {
extend: ‘Ext.app.ViewController‘,
alias: ‘controller.foo‘,
control: {
‘#‘: { // matches the view itself
collapse: ‘onCollapse‘
},
button: {
click: ‘onAnyButtonClick‘
}
}
});
The key difference between listeners and selectors can be seen above. The “button” selector will match any button in this view or any child view, irrespective of depth, even if that button belongs to a great-grandchild view. In other words, selector-based handlers do not respect encapsulation boundaries. This behavior is consistent with previous Ext.app.Controller behavior and can be a useful technique in limited situations.
Lastly, these event domains respect nesting and effectively “bubble” an event up the view hierarchy. That is to say, when an event fires, it’s first delivered to any standard listeners. Then, it’s delivered to its owning ViewController, followed by its parent ViewController (if any) on up the hierarchy. Eventually, the event is delivered to the standard “component” event domain to be handled by Ext.app.Controller-derived controllers.
http://wangyuelucky.blog.51cto.com/1011508/1610248/
原文:http://www.cnblogs.com/coolzdp/p/7398184.html