使用和功能新的Ext.app.EventDomain [英] Use and function of the new Ext.app.EventDomain

查看:139
本文介绍了使用和功能新的Ext.app.EventDomain的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们拥有大量的应用程序,它们共享一些部件(数据/后端/前端)。用户可以访问一个或多个应用程序,并且当前用户需要逐个加载它们。我们的客户不喜欢这样做,所以我们现在将所有重构都放在一个巨大的应用程序中,客户端自己解决要加载的模块。第一个测试看起来很好,由于我们的自定义模块制作工具,加载时间是一分钟。



现在我偶然发现了新的$ code Ext.app。 EventDomain ,并想知道我们是否应该将其实现到我们的重构中,一个棘手的部分是事件。我们还考虑在桌面上使用路由。但是这个争论还在继续。



我们应该使用 Ext.app.EventDomain 我们的意思是Sencha Touch正在使用路由,但没有使用EventBus,我会说Sencha Touch性能至关重要,所以似乎有两个框架在这里不同的原因?

解决方案

Ext。 app.EventDomain 不是用于本身;相反,如果需要,您可以实现自定义事件域。事件域背后的想法是非常简单的:它是在不是Ext.Component派生的应用程序部分之间传递事件的一种方法。



最常用的是Controller绑定:在4.1中只能直接调用其他控制器的方法(硬绑定),这对测试来说非常不好。在4.2中,您可以让Controller听其他控件的事件(软绑定),并且具有明确的逻辑分离,因此不是:

  Ext.define('MyApp.controller.Foo',{
extends:'Ext.app.Controller',

doSomething:function(){
this.getController ('Bar')doSomethingElse();
}
});

Ext.define('MyApp.controller.Bar',{
extends:'Ext.app.Controller',

doSomethingElse:function(){
//这里的问题是这个逻辑属于Bar控制器
//但是这个方法必须从Foo控制器调用,
//这意味着Bar应该永远在Foo

$ b}
});

您可以:

  Ext.define('MyApp.controller.Foo',{
extends:'Ext.app.Controller',

doSomething:function(){
this.fireEvent('doSomethingElse');
}
});

Ext.define('MyApp.controller.Bar',{
extends:'Ext.app.Controller',

init:function(){
this.listen({
controller:{
'*':{//'*'表示任何控制器
doSomethingElse:this.doSomethingElse
}

});
},

doSomethingElse:function(){
//不再是问题 - Foo触发事件,如果Bar
//恰好在周围,它反应并做任何它想要的;
//的好处是没有直接的方法调用
//所以我们不必看异常和做其他
//不必要的东西
...
}
});

也可以听自己的事件 - 这不是你可能会使用的东西生产,但是一个很好的副作用,可以非常成功地用于控制器单元测试。



除了其他控制器的事件,Controller现在可以收听Store,Direct提供商和全球事件,有时可能有用。



当4.2发布时,我打算写下这个;希望这有助于一段时间。


We have a huge amount of applications which all are sharing some parts (data/backend/frontend). Users may have access to one or more applications and currently the user need to load them one by one. Our Customer don't like this so we are now refactoring all into one huge application where the client itself resolves which module to load. First test looked good and due to our custom modulebuilder tool the loading times are at a min.

Now I stumbled over the new Ext.app.EventDomain and wondered if we should implement it into our refactoring cause one tricky part are the events. We also have the consideration of using routing on the table. But this debate is still going.

So should we use Ext.app.EventDomain and if so how is it used or should we better stay with a custom routing?

I mean Sencha Touch is using routing but no EventBus and I would say that Sencha Touch is performance critical so it seems there is a reason why both frameworks are differ here?

解决方案

Ext.app.EventDomain is not intended to be used per se; rather, you can implement custom event domains if you need them. The idea behind event domains is quite simple: it's a way to pass events between application parts that happen not to be Ext.Component-derived.

The most frequent use is Controller binding: in 4.1 it was only possible to call other Controllers' methods directly (hard binding), which is very bad for testing. In 4.2 you can have a Controller listen to other Controllers' events instead (soft binding) and have clear logic separation, so instead of:

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?
        ...
    }
});

You can do:

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.
        ...
    }
});

It's also ok to listen to your own events -- which is not something you'd probably use in production but is a nice side effect that can be used very successfully for controller unit testing.

Besides other Controllers' events, a Controller can now listen to Store, Direct provider and global events, which may be useful at times.

I plan to write up on this when 4.2 is released; hope this helps a bit until then.

这篇关于使用和功能新的Ext.app.EventDomain的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆