extjs - Uso y función del nuevo Ext.app.EventDomain

extjs4.2

Question

Tenemos una gran cantidad de aplicaciones que comparten partes (data / backend / frontend). Los usuarios pueden tener acceso a una o más aplicaciones y actualmente el usuario debe cargarlas una a una. A nuestro cliente no le gusta esto, por lo que ahora estamos refacturando todo en una aplicación enorme donde el cliente mismo resuelve qué módulo cargar. La primera prueba se vio bien y gracias a nuestra herramienta modulebuilder personalizada, los tiempos de carga son a un mínimo.

Ahora tropecé con el nuevo Ext.app.EventDomain y me pregunté si deberíamos implementarlo en nuestra causa de refactorización. Una parte complicada son los eventos. También tenemos la consideración de usar el enrutamiento en la mesa. Pero este debate todavía está en marcha.

Entonces, ¿deberíamos usar Ext.app.EventDomain ser así, ¿cómo se usa o deberíamos seguir con un enrutamiento personalizado?

Quiero decir, Sencha Touch está utilizando el enrutamiento pero no EventBus y yo diría que Sencha Touch es crítico para el rendimiento, así que parece que hay una razón por la cual ambos marcos difieren aquí.

Answer 1

Ext.app.EventDomain no está destinado a ser utilizado per se ; más bien, puede implementar dominios de eventos personalizados si los necesita. La idea detrás de los dominios de eventos es bastante simple: es una forma de pasar eventos entre partes de la aplicación que, por casualidad, no se derivan de Ext.Component.

El uso más frecuente es la vinculación del Controlador: en 4.1 solo fue posible llamar directamente a los métodos de otros Controladores (enlace fuerte), lo cual es muy malo para las pruebas. En 4.2, puede hacer que un controlador escuche los eventos de otros controladores (enlace suave) y tenga una separación lógica clara, por lo que en lugar de:

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

Tu puedes hacer:

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

También está bien escuchar sus propios eventos, que no es algo que probablemente utilizaría en la producción, pero es un buen efecto secundario que se puede usar con mucho éxito para las pruebas de la unidad controladora.

Además de otros eventos de Controladores, un Controlador ahora puede escuchar Store, Direct provider y eventos globales, que a veces pueden ser útiles.

Planeo escribir sobre esto cuando se publique 4.2; Espero que esto ayude un poco hasta entonces.