Ext JS 4.1 Beta 1 Now Available
We are very excited to get Ext JS 4.1.0 Beta 1 out to the community! Contained in this release are literally hundreds of bug fixes. As a first beta, there are several issues that we wanted to fix but decided that they were not critical enough to hold up the release any longer. These are documented in the known issues section of the release notes file in the distribution.
You can download Ext JS 4.1 Beta 1 here: http://cdn.sencha.io/ext-4.1.0-beta-1.zip
I wanted to take a moment to cover some of the internals that have changed. Some of these are new since 4.1 PR1, while other changes were introduced in 4.1 PR1 but have not been previously covered.
For other details, see my blog post http://www.sencha.com/blog/whats-new-in-ext-js-4-1/
As result of the design for the layout engine in 4.1, it is possible for improper configuration (or a bug) to cause a layout run to fail to complete all of its calculations. When this occurs, the layout simply stops and the partial results that have been flushed to the DOM are all that is visible. In some cases, the layout may be 99% complete and the failure may go undetected or appear as a minor visual anomaly. In other cases, the layout may fail early and leave the UI in a clearly broken state (much like a JS error during layout would do in previous versions).
The first step if you suspect you are seeing a layout failure is to enable the layout diagnostics. This is done by replacing the normal "ext-all.js" file with "ext-all-dev.js" and adding a couple additional scripts. Like so:
Obviously, the path to Ext JS 4.1 will vary for your environment. With the above modifications, the diagnostic log can be viewed in Firebug's or Web Inspector's console. For IE, the logs are stored in memory and can be displayed by typing the following in the address bar once the page has loaded:
This can be bookmarked to create a "bookmarklet". The log is limited to 750 lines which can be changed like so:
Model and idProperty
Ext.log.max = 1500;
A common mis-configuration of Model is to not specify a proper "idProperty". This config property identifies the primary key of the model. This is easy to forget because "idProperty" defaults to "id". In 4.0, if there was no actual field in the Model by this name, you could encounter JS errors under some circumstances. In 4.1, this has been fixed by automatically defining the field by this name as a "string" property if there is no definition given.
This fix can, however, have unexpected side-effects. If you notice that your models have gained an "id" property this is most likely why. The solution is to configure your models with the correct "idProperty" value.
Fields and Their Layouts
In Ext JS 4.1 PR1 and then again in Beta 1, fields and field layouts have undergone several internal changes. Before I dive into them, however, I wanted to cover several new configuration properties related to field rendering. We have talked to several customers who needed to replace the rendering logic of fields (things like the "renderTpl", "fieldSubTpl" or "labelableRenderTpl") to accomplish some basic tweaks for their applications. While this works, the properties being overridden are internal and have changed several times since 4.0. Rather than continue this cycle, we wanted to provide a more stable way to augment fields.
In Beta 1, we have added several "micro" render templates to decorate fields. Typically these will be just strings of simple markup, but they can be full XTemplates. These decorators are as follows:
Labelable: beforeLabelTpl, afterLabelTpl, beforeSubTpl, afterSubTpl, beforeLabelTextTpl, afterLabelTextTpl and labelAttrTpl
Checkbox: beforeBoxLabelTpl, afterBoxLabelTpl, beforeBoxLabelTextTpl, afterBoxLabelTextTpl, boxLabelAttrTpl
HtmlEditor: beforeTextAreaTpl, afterTextAreaTpl, beforeIFrameTpl, afterIFrameTpl, iframeAttrTpl
The use of "afterLabelTextTpl" is demonstrated in two of the examples: /examples/form/dynamic.html and /examples/form/contact-form.html to render a simple "required field" indicator. Their role in rendering is probably obvious from their name. For further details, refer to the docs or the source for the various fieldSubTpl's or labelableRenderTpl. If there are other decorators that might be helpful, just let us know.
In 4.0 and 4.1 PR1 field layouts were a rather complex balance of positioning, floating and measurement with subtle timing dependencies. In Beta 1, field layouts have been modified extensively to allow the browser to do much more of this work. To support IE6 this required the use of tables. There are still some calculations required, typically around height, but this approach eliminated lots of calculation and measurement that we previously had to perform on each field, the cost of which added up quickly.
In 4.1 PR1, panel collapse was consolidated entirely into Panel. In 4.0, panel collapse was handled by Panel in many cases, but when contained in an Accordion or Border layout, these layouts would get very involved in the collapse/expand process. This change is unlikely to have impact on most applications, but could be important if the animation or other properties of collapsing have been customized.
Masking is now only shared for modal windows. Non-floating and non-modal components will now create their own masks. While support for using Ext.LoadMask on elements has been deprecated in favor of the Ext.dom.Element mask() and unmask() methods, the ability to mask elements is still supported.
Mask management has been improved to handle re-sizing and hiding of the owning component
In 4.1 Beta 1, the DragDropManager now consults the z-index to identify the top-most target of a drop. While this will fix many use cases of overlapping drop targets, it could also impact customized drag/drop processing.
There were many question about the "Neptune Theme Preview" mentioned in the blog. To clarify, Neptune will only supported on modern browsers (not IE) in Ext JS 4.1 even when the release is final. If you need IE support, Neptune will not be an option yet.
We hope to hear from you all about any issues you run into as the beta process continues. At this point we really need to hear about any compatibility problems you might have. Our goal is to be as backwards compatible with 4.0 as possible.
Please remember, when posting an issue or bug, a test case always helps expedite the process. See http://www.sencha.com/forum/showthre...o-report-a-bug
Some other useful articles on 4.1 in general: