我们有大量的应用程序都在共享一些部分(数据/后端/前端)。用户可以访问一个或多个应用程序,当前用户需要逐个加载它们。我们的客户不喜欢这样,因此我们现在将所有内容重构为一个巨大的应用程序,客户端自己解析要加载的模块。第一次测试看起来不错,由于我们的自定义模块构建工具,加载时间是一分钟。
现在我偶然发现了新的Ext.app.EventDomain
并且想知道我们是否应该将它实现到我们的重构中,因为事件中有一个棘手的部分。我们还考虑在表上使用路由。但这场辩论仍在继续。
我们应该使用Ext.app.EventDomain
,如果是这样,它是如何使用的,还是应该更好地使用自定义路由?
我的意思是Sencha Touch正在使用路由,但没有EventBus,我会说Sencha Touch对性能至关重要,所以看起来两个框架在这里有不同的原因?
答案 0 :(得分:9)
Ext.app.EventDomain
无意使用本身;相反,您可以在需要时实现自定义事件域。事件域背后的想法非常简单:它是一种在不是Ext.Component派生的应用程序部分之间传递事件的方法。
最常用的是控制器绑定:在4.1中,只能直接调用其他控制器的方法(硬绑定),这对测试非常不利。在4.2中,您可以让控制器监听其他控制器的事件(软绑定)并具有明确的逻辑分离,因此不是:
Ext.define('MyApp.controller.Foo', {
extend: 'Ext.app.Controller',
doSomething: function() {
this.getController('Bar').doSomethingElse();
}
});
Ext.define('MyApp.controller.Bar', {
extend: 'Ext.app.Controller',
doSomethingElse: function() {
// The problem here is that this logic belongs to Bar controller
// but this method has to be called from Foo controller,
// which means Bar should always be around whenever Foo
// needs to call it. Race conditions, anyone?
...
}
});
你可以这样做:
Ext.define('MyApp.controller.Foo', {
extend: 'Ext.app.Controller',
doSomething: function() {
this.fireEvent('doSomethingElse');
}
});
Ext.define('MyApp.controller.Bar', {
extend: 'Ext.app.Controller',
init: function() {
this.listen({
controller: {
'*': { // '*' means any controller
doSomethingElse: this.doSomethingElse
}
}
});
},
doSomethingElse: function() {
// Not a problem anymore -- Foo fires an event, and if Bar
// happens to be around, it reacts and does whatever it wants;
// the benefit is that there is no direct method calling
// so we don't have to watch for exceptions and do other
// unnecessary stuff.
...
}
});
也可以听你自己的事件 - 这不是你可能在生产中使用的东西,但它是一个很好的副作用,可以非常成功地用于控制器单元测试。
除了其他控制器的事件,Controller现在可以监听Store,Direct提供者和全局事件,这些事件有时可能很有用。
我计划在4.2发布时写下这个;希望在此之前有所帮助。