Ext JS 中的视图控制器

Ext JS 提供了一些激动人心的改进，供您在应用程序架构中使用。我们添加了对 ViewModel 和 MVVM 以及视图控制器的支持，以增强 MVC 应用程序。最棒的是，这些选择不是相互排斥的，因此您可以逐步引入这些功能，甚至将它们混合使用。

应用程序级控制器

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

这些控制器在应用程序启动时创建，并在应用程序的生命周期中一直存在。在其生命周期中，控制器感兴趣的视图将出现和消失。甚至可能存在控制器管理的视图的多个实例。

挑战

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

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

视图控制器

虽然 Ext JS 5+ 向后兼容传统的应用程序级控制器，但它引入了一种新的控制器类型来处理这些挑战：Ext.app.ViewController。ViewController 通过以下方式实现这一点

• 使用“监听器”和“引用”配置简化了与视图的连接。
• 利用视图的生命周期自动管理其关联的 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），没有指定“范围”。在内部，事件系统将 Bar 文本字段的默认范围解析为其所属的 ViewController。

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

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

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

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

上面的例子利用了 Ext JS 中的两个新特性：命名范围和声明式监听器。我们这里将重点关注命名范围。命名范围有两个有效值：“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');
    }
});

这类似于分配一个“fooGrid”的 itemId 并执行：“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” 事件域的新类型事件域的实例。此事件域允许 ViewController 使用标准的 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 很好地配合使用，因此您可以将这些方法及其各自的优势结合起来。