Ext js 4.2 beta version released

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 previusly 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 wowould your CT: 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 wocould 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

Improved support for ie10 (ie10 is a freak ).

RTL

In addition to grid, the long anticipated support of right-to-left (or RTL) ages 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 (obviusly) 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" shocould be flipped as well even though their comprehenations wowould 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 ages, this handling is what wocould be desired in just about every use case.

In all browsers before t 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 your things to flip in to RTL.

The additional RTL support code is not supported 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 supported ded 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.

The RTL language is supported. I need to study it. I still don't know what it is.

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" doesn't 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. obviusly, 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 supports foreach statements. This is good news. You can directly List objects.

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 can do this:

Code:

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

The above wowould 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 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 your SS pages.

Shocould you not use them, these internal changes shocould be transparent to your applications. But if you have previusly tried to unit test your controllers and found that you cocould not... You shoshould try again with ext JS 4.2.

The generation method of the MVC method has changed (the above two pieces of code ).

It is easier to write unit tests for the Controller class. You can create application base classes in a subset to share models, stores, and views.

Trees

In ext JS 4.2, the specified 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 improved the tree. The main change is to change the nodeinterface class to Ext. Data. treemodel, that is, to define the tree model in the future, which should be extended from 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 shocould, therefore, be minimal to your styling.

This change also affects anchor layout and column layout.

The automatic container layout is modified and an encapsulation element is added to encapsulate the style. The anchor and column la s are also modified.

Life-cycle Optimizations

We have also passed med 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 cocould 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 wocould fire for each component you created and they wocould 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 ).

The component lifecycle is optimized. One change is that the add and remove container events are no longer bubbling.