Ext JS 中的 ViewControllers

Ext JS 为您在应用程序架构中使用提供了一些令人兴奋的改进。我们添加了对 ViewModels 和 MVVM 以及 ViewControllers 的支持，以增强 MVC 应用程序。最棒的是，这些选择不是互斥的，因此您可以逐步引入这些功能，甚至可以混合使用它们。

应用程序级控制器

Controller 是从 Ext.app.Controller 派生的类。这些控制器使用类似 CSS 的选择器（称为“组件查询”）来匹配组件并响应其事件。它们还使用“refs”来选择和检索组件实例。

这些控制器在应用程序启动时创建，并在应用程序的生命周期内保持存在。在其生命周期内，控制器感兴趣的视图将会来来去去。甚至可能存在控制器管理的视图的多个实例。

挑战

对于大型应用程序，这些技术可能会带来某些挑战。

在这样的环境中，视图和控制器可能由多个开发团队编写并集成到最终应用程序中。确保控制器仅对其预期的视图做出反应可能很困难。此外，开发人员通常希望限制在应用程序启动时创建的控制器的数量。虽然通过一些努力可以延迟创建控制器，但它们无法销毁，因此即使不再需要它们，它们仍然存在。

ViewControllers

虽然 Ext JS 5+ 向后兼容旧版应用程序级控制器，但它引入了一种旨在应对这些挑战的新型控制器：Ext.app.ViewController。ViewController 通过以下方式实现此目的

• 简化了使用“监听器”和“reference”配置连接到视图。
• 利用视图的生命周期自动管理其关联的 ViewController。
• 基于与托管视图的一对一关系，降低了 ViewController 的复杂性。
• 提供封装以使嵌套视图可靠。
• 保留在关联视图下方的任何级别选择组件并监听其事件的能力。

监听器

对于 ViewControllers 的目的，我们可以只看两个示例。第一个是在视图中的子项上基本使用监听器配置

Ext.define('MyApp.view.foo.Foo', {
    extend: 'Ext.panel.Panel',
    xtype: 'foo',
    controller: 'foo',

    items: [{
        xtype: 'textfield',
        fieldLabel: 'Bar',
        listeners: {
            change: 'onBarChange'  // no scope given here
        }
    }]
});

Ext.define('MyApp.view.foo.FooController', {
    extend: 'Ext.app.ViewController',
    alias: 'controller.foo',

    onBarChange: function (barTextField) {
        // called by 'change' event
    }
});

上面对监听器的使用显示了一个命名的事件处理程序 (onBarChange)，没有指定“scope”。在内部，事件系统将 Bar 文本字段的默认 scope 解析为其拥有的 ViewController。

从历史上看，监听器配置保留供组件的创建者使用，那么视图如何监听自己的事件，或者可能监听其基类触发的事件？答案是我们需要使用显式 scope

Ext.define('MyApp.view.foo.Foo', {
    extend: 'Ext.panel.Panel',
    xtype: 'foo',
    controller: 'foo',

    listeners: {
        collapse: 'onCollapse',
        scope: 'controller'
    },

    items: [{
        ...
    }]
});

上面的示例利用了 Ext JS 中的两个新功能：命名 scope 和声明式监听器。我们将在此处重点关注命名 scope。命名 scope 有两个有效值：“this”和“controller”。在编写 MVC 应用程序时，我们几乎总是使用“controller”，这显然会导致查看该视图的 ViewController（而不是创建实例的视图的 ViewController）。

由于视图是 Ext.Component 的一种类型，我们已为此视图分配了“xtype”，这使其他视图能够以与此视图创建其文本字段相同的方式创建此视图的实例。要了解这是如何结合在一起的，请考虑一个使用此视图的视图。例如

Ext.define('MyApp.view.bar.Bar', {
    extend: 'Ext.panel.Panel',
    xtype: 'bar',
    controller: 'bar',

    items: [{
        xtype: 'foo',
        listeners: {
            collapse: 'onCollapse'
        }
    }]
});

在这种情况下，Bar 视图正在创建 Foo 视图的实例作为其项目之一。此外，它正在监听 collapse 事件，就像 Foo 视图一样。Foo 视图声明的监听器将在 Foo 的 ViewController 上触发，而 Bar 视图中声明的监听器将在 Bar 的 ViewController 上触发。

参考

编写控制器逻辑时最常见的遗留问题之一是如何获得完成特定操作所需的组件。像这样简单的东西

Ext.define('MyApp.view.foo.Foo', {
    extend: 'Ext.panel.Panel',
    xtype: 'foo',
    controller: 'foo',

    tbar: [{
        xtype: 'button',
        text: 'Add',
        handler: 'onAdd'
    }],

    items: [{
        xtype: 'grid',
        ...
    }]
});

Ext.define('MyApp.view.foo.FooController', {
    extend: 'Ext.app.ViewController',
    alias: 'controller.foo',

    onAdd: function () {
        // ... get the grid and add a record ...
    }
});

但是应该如何获取网格组件呢？所有技术都要求您在网格上放置一些可识别的属性，以便唯一标识它。较旧的技术使用“id”配置（和 getCmp）或“itemId”配置（使用“refs”或某些组件查询方法）。“id”的优点是查找速度快，但由于这些标识符必须在整个应用程序和 DOM 中都是唯一的，因此这通常是不希望的。使用“itemId”和某种形式的查询更灵活，但需要执行搜索才能找到所需的组件。

使用 reference 配置，我们只需将“reference”添加到网格并使用 lookupReference 来获取它

Ext.define('MyApp.view.foo.Foo', {
    extend: 'Ext.panel.Panel',
    xtype: 'foo',
    controller: 'foo',

    tbar: [{
        xtype: 'button',
        text: 'Add',
        handler: 'onAdd'
    }],

    items: [{
        xtype: 'grid',
        reference: 'fooGrid'
        ...
    }]
});

Ext.define('MyApp.view.foo.FooController', {
    extend: 'Ext.app.ViewController',
    alias: 'controller.foo',

    onAdd: function () {
        var grid = this.lookupReference('fooGrid');
    }
});

这类似于分配 itemId “fooGrid” 并执行：“this.down(‘#fooGrid’)”。然而，幕后的区别非常显着。首先，reference 配置指示组件向其拥有的视图注册自身（在这种情况下，通过 ViewController 的存在来识别）。其次，lookupReference 方法只是查询缓存以查看是否需要刷新引用（例如，由于容器上的添加或删除）。如果一切正常，它只会从缓存中返回引用。或者，用伪代码表示

lookupReference: (reference) {
    var cache = this.references;
    if (!cache) {
        Ext.fixReferences(); // fix all references
        cache = this.references; // now the cache is valid
    }
    return cache[reference];
}

换句话说，没有搜索，并且当需要时，一次性修复了因从容器中添加或删除项目而损坏的链接。正如我们将在下面看到的，这种方法除了效率之外还有其他好处。

封装

选择器与控制器 refs 配置的结合使用非常灵活，但同时也存在一定的风险。这些选择器“看到”组件层次结构所有级别的所有内容这一事实既强大又容易出错。例如，控制器在隔离运行时可能 100% 工作，但一旦引入其他视图就会失败，因为其选择器与新视图具有不需要的匹配项。

这些问题可以通过遵循某些实践来管理，但是当将监听器和引用与 ViewController 一起使用时，这些问题根本不可能发生。这是因为监听器和引用配置仅与其拥有的 ViewController 连接。视图可以自由选择在该视图中唯一的任何引用值，因为知道这些名称不会暴露给视图的创建者。

同样，监听器在其拥有的 ViewController 上解析，并且不会意外地分派到其他控制器中具有错误选择器的事件处理程序。虽然监听器通常优于选择器，但在需要基于选择器的方法的那些情况下，这两种机制可以很好地协同工作。

为了完成此模型，视图需要触发可以由其拥有的视图的 ViewController 使用的事件。ViewController 中有一个辅助方法用于此目的：fireViewEvent。例如

Ext.define('MyApp.view.foo.FooController', {
    extend: 'Ext.app.ViewController',
    alias: 'controller.foo',

    onAdd: function () {
        var record = new MyApp.model.Thing();
        var grid = this.lookupReference('fooGrid');
        grid.store.add(record);

        this.fireViewEvent('addrecord', this, record);
    }
});

这为该视图的创建者启用了标准形式的监听器

Ext.define('MyApp.view.bar.Bar', {
    extend: 'Ext.panel.Panel',
    xtype: 'bar',
    controller: 'bar',

    items: [{
        xtype: 'foo',
        listeners: {
            collapse: 'onCollapse',
            addrecord: 'onAddRecord'
        }
    }]
});

监听器和事件域

在 Ext JS 4.2 中，通过引入事件域，MVC 事件调度器被通用化。这些事件域拦截事件，并在事件触发时将它们调度到由选择器匹配控制的控制器。 “component”事件域具有完整的组件查询选择器，而其他域具有更有限的选择器。

使用 Ext JS 5+，每个 ViewController 创建一种称为“view”事件域的新型事件域的实例。此事件域允许 ViewControllers 使用标准 listen 和 control 方法，同时将其范围隐式地限制为其视图。它还添加了一个特殊的选择器来匹配视图本身

Ext.define('MyApp.view.foo.FooController', {
    extend: 'Ext.app.ViewController',
    alias: 'controller.foo',

    control: {
        '#': {  // matches the view itself
            collapse: 'onCollapse'
        },
        button: {
            click: 'onAnyButtonClick'
        }
    }
});

以上可以看出监听器和选择器之间的关键区别。“button”选择器将匹配此视图或任何子视图中的任何按钮，无论深度如何，即使该按钮属于曾孙视图。换句话说，基于选择器的处理程序不尊重封装边界。此行为与以前的 Ext.app.Controller 行为一致，并且在有限的情况下可能是一种有用的技术。

最后，这些事件域尊重嵌套，并有效地将事件“冒泡”到视图层次结构中。也就是说，当事件触发时，它首先传递给任何标准监听器。然后，它传递给其拥有的 ViewController，然后传递给其父 ViewController（如果有），直到层次结构向上。最终，事件传递到标准“component”事件域，以便由 Ext.app.Controller 派生的控制器处理。

生命周期

大型应用程序的常用技术是在首次需要时动态创建控制器。这可以帮助减少应用程序的加载时间，并通过不激活所有潜在的控制器来帮助运行时性能。以前版本中对此的限制是，一旦创建，这些控制器将保持在应用程序中处于活动状态。无法销毁它们并释放其资源。同样，这并没有改变控制器可以具有任意数量的关联视图（包括无）的现实。

但是，ViewController 在组件生命周期的早期创建，并在整个生命周期内绑定到该视图。当该视图销毁时，ViewController 也同样销毁。这意味着 ViewController 不再被迫管理没有视图或多个视图的状态。

这种一对一的关系意味着引用跟踪得到了简化，并且不再容易泄漏已销毁的组件。ViewController 可以实现以下任何方法，以便在其生命周期的关键点执行任务

• beforeInit - 可以覆盖此方法，以便在调用视图的 initComponent 方法之前对视图进行操作。此方法在控制器创建后立即调用，这发生在从 Component 构造函数调用的 initConfig 期间。
• init - 在视图上调用 initComponent 后不久调用。现在视图已初始化，这是执行控制器初始化的典型时间。
• initViewModel - 在创建视图的 ViewModel 时调用（如果定义了一个 ViewModel）。
• destroy - 清理并返回资源（请务必调用 callParent）。

结论

我们认为 ViewControllers 将大大简化您的 MVC 应用程序。它们与 ViewModels 也非常配合使用，因此您可以结合这些方法及其各自的优势。