Ext JS 4.2 Beta版发布

原文：http://www.sencha.com/forum/showthread.php?251214-Ext-JS-4.2-Beta-is-Now-Available

Today we are excited to make available the beta release of Ext JS 4.2.

For those eager to get the bits, you can download the beta here:

http://cdn.sencha.com/ext-4.2.0-beta.zip

The most significant change in Ext JS 4.2 is in the Grid component. There is an excellent newsletter article on this, so I highly recommend taking a look at it for details. In addition to the exciting grid improvements, Ext JS 4.2 contains all of the bug fixes found in Ext JS 4.1.2 and Ext JS 4.1.3 that have previously been shipped only to support subscribers.

Let’s dive in to the other highlights of this release.

IE 10

With Ext JS 4.2 we now have much improved IE 10 support. The introduction of IE10 brings an entirely new challenge to consider in your applications, however: 2 quirks modes! That’s right. All other browsers to date have a strict mode and a quirks mode (the mode you get with no DOCTYPE specified). With IE10, strict mode is enabled as you would expect: when you specify the DOCTYPE. What is a surprise is that when you do not specify a DOCTYPE, the new “interoperable quirks” mode is enabled. This quirks mode is not at all like previous “IE Quirks” modes. The old quirks mode is enabled only with the following meta tag:

Code:

<meta http-equiv="X-UA-Compatible" content="IE=5">

This has forced us to reconsider some of the UA detection flags we provide like Ext.isIE because these are almost always intended to check for the old IE behaviors. But in the new quirks mode, IE behaves very much like Chrome or Firefox do in their quirks mode so these checks would cause all kinds of work around code to activate.

For the official story from Microsoft on IE 10 and its document modes, see http://blogs.msdn.com/b/ie/archive/2...e-in-ie10.aspx

改进了对IE10的支持（IE10就是一个怪胎）。

RTL

In addition to Grid, the long anticipated support of Right-to-Left (or RTL) languages has arrived in Ext JS 4.2! The core functionality of RTL is provided as a set of overrides in the Ext.rtl namespace. Enabling RTL on your viewport is a two-line addition:

Code:

Ext.define('MyApp.view.Viewport', {
    extend: 'Ext.container.Viewport',
    requires: [ 'Ext.rtl.*' ],
    rtl: true
});

The effect of “rtl” is quite (obviously) dramatic: it is as if a mirror were placed next to the screen and everything is flipped horizontally. After some deliberation, we decided that for the majority of uses, certain properties like “dock” and “region” should be flipped as well even though their configurations would seem to be violated. For example, “dock: ‘left’” will dock the item on the right in RTL mode and likewise, “region: ‘east’” will place the region on the left. This is because the reasons for choosing “left” or “right” in UI design are typically about visual priority and “natural” reading order. Since these are flipped in RTL languages, this handling is what would be desired in just about every use case.

In all browsers except for legacy IE (that is, IE6 in all modes and IE7 to IE9 in quirks mode), it is possible to change the “rtl” mode of child containers, say for a portal where not all portlets have the same RTL mode. In legacy IE, however, RTL is a global option. Simply including the RTL css file will cause many things to flip in to RTL.

The additional RTL support code is not included in ext-all.js but instead in ext-all-rtl.js. Of course, using Sencha Cmd, your application’s build will only include the pieces you need and the ext-all-*.js files are only important at development time.

The extra CSS rules are likewise not included in ext-all.css since most users do not need them. Enabling them is as simple as switching to ext-all-rtl.css. To support legacy IE, you will need to dynamically determine whether to include ext-all.css or ext-all-rtl.css since including ext-all-rtl.css will cause the much of the UI to flip to RTL mode. You will still need the support code and “rtl” config to complete the functionality, but the RTL rule CSS selectors in ext-all-rtl.css will match all components and containers in IE6.

支持RTL语言，这个需要研究一下，还不是很明白是什么东西。

XTemplate

Ext JS 4.1 released a ton of new bells and whistles in XTemplate, but like any language, there are always more useful features out there. In Ext JS 4.2, XTemplate has learned a couple new tricks. These can be seen in this example:

Code:

<tpl foreach="someObject" between=",">
    {$}={.}
</tpl>

The new “foreach” feature is similar to “for” except that it iterates the properties of a given object. The “{$}” replacement picks up the name of the current property in the loop while “{.}” is the current value. Finally, the “between” option allows you to include a string between each of the items. Obviously, this is handy for things like comma-separated lists as it avoids the dreaded dangling comma after the last item. The “between” option also works on “for” loops.

Xtemplate支持foreach语句了，这是好消息啊，可以直接列对象了。

MVC

In Ext JS 4.1.3 we started a series of internal fixes to the MVC core classes to help with larger applications that needed to share models, views and controllers between pages. In previous versions, you could do this:

Code:

Ext.define('MyApp.controller.Main', {
    views: [
        'Foo'
        'Common.views.Bar'
    ]
});

The above would produce two accessor methods: “getFoo” and “getCommonViewsBar”. In 4.1.3, we introduced an alternative absolute name syntax.

Code:

Ext.define('MyApp.controller.Main', {
    views: [
        'Foo',
        'Bar@Common.views' // maps to Common.views.Bar
    ]
});

The accessor methods in the above are: getFoo and getBar.

Beyond convenience methods like these, the MVC changes have been targeted to also allow you to more easily unit test your controller classes and to share your application classes across pages.

To enable controllers to be unit tested, we have modified the Ext.app.Controller class to no longer require an Ext.app.Application instance in order to be instantiated. This also affects how the events wire up worked since that required the application and a helper object called the “event bus”.

You can now write a standard-looking Ext.app.Application derived class and pass its name to Ext.application:

Code:

Ext.define('MyApp.Application', {
    extend: 'Ext.app.Application',
    name: 'MyApp'
...
});

Ext.application('MyApp.Application');

All of the special processing of dependencies such as “models”, “views” and “controllers” now takes place during class derivation, so you can write your own application base classes to reuse across pages.

Should you not use them, these internal changes should be transparent to your applications. But if you have previously tried to unit test your controllers and found that you could not … you should try again with Ext JS 4.2.

MVC方法的生成方式改变了（上面两段代码）。

可以更容易为控制器类编写单元测试了。可以子集创建应用程序基类来共享模型、Store和视图。

Trees

In Ext JS 4.2, the many grid improvements also serve for trees. Most importantly, the buffered rendering plugin.

One challenge that people encounter when using trees is the NodeInterface class. This class gets injected “on top” of your model class and that can create problems since it may override methods you want to implement. In Ext JS 4.1.3, we added Ext.data.TreeModel as a class from which you can derive your own models for use in a tree. Because Ext.data.TreeModel gets the NodeInterface applied to it, your models are free to override any method you need. The change is simple:

Ext JS 4.2对树进行了改进。主要改变是将NodeInterface类修改为Ext.data.TreeModel，也就是，以后定义树的模型，要从Ext.data.TreeModel扩展。

Code:

Ext.define('MyApp.models.Foo', {
    extend: 'Ext.data.TreeModel',
    ...
});

Auto Container Layout

To some degree this is largely an internal change, but it will surely have impact to some applications. In Ext JS 4.1, the auto container layout class had to manage all of its child components individually. This posed performance challenges for containers that had lots of child components, so in Ext JS 4.2, we have added wrapping elements to create a bounding box around auto container contents.

We have heavily tested the interaction of these elements with things like child margins, body padding, scrolling overflow, text flow and the like. The side-effects should, therefore, be minimal to your styling.

This change also affects anchor layout and column layout.

对自动容器布局进行了修改，添加了一个封装元素来封装样式。anchor布局和column布局也做了修改。

Life-cycle Optimizations

We have also performed a good deal of tuning on the component life-cycle methods (like setUI). We moved more of the DOM element preparation work into the beforeRender phase to ensure that the markup we produce is right and does not need tweaking in afterRender.

One change in this area that could affect your applications is that the “add” and “remove” container events no longer bubble by default. In Ext JS 4.0/4.1, these events would fire for each component you created and they would bubble up to the top of the component hierarchy. In almost every case, there were no listeners to these events and all this work was for naught. In Ext JS 4.2, these events no longer bubble, which allows us to take advantage of our optimized event listener detection and maybe avoid even calling fireEvent (if there are no listeners).

组件生命周期做了优化。其中一个改变是add和remove容器事件不再冒泡。