From Learn About the Ext JavaScript Library

Summary of Major Changes

Here's a high-level summary of what's new in 2.0. There have been countless minor improvements, bug fixes and other changes across the framework from 1.x to 2.0. It would be impossible to list everything, so this overview is focused on the major areas where either the architecture has shifted, or there is some entirely new area of functionality. Each item is explained in detail in the sections following this summary.

• Component Model
  While the Component and BoxComponent classes existed in 1.x, they were not fully integrated throughout the framework. In 2.0, both classes have been greatly improved and now form the base of all major components. While these classes are intended to be mostly invisible to the developer, an understanding of the Component life cycle in 2.0 is fundamental to taking your Ext skills to the next level. See Details
• Container Model
  There are now several core classes available for building widgets and layouts that can contain other components. Container provides the fundamental framework for containment and layout of components, and is essential to the entire visual framework of Ext. Panel extends Container to provide base application-specific UI functionality, and is probably the most important class in the container hierarchy. Window is a special type of Panel that enables true desktop-style web applications, and Viewport is a utility container specifically designed for implementing full-browser-window web applications. See Details
• Layouts
  In 1.x, layout was centered around BorderLayout and its related classes. In 2.0, an entire layout architecture built on the new container and layout classes has been created. BorderLayout has now been joined by nine additional layout styles, and the class hierarchy has been redesigned for maximum extensibility. Layouts are also better managed by the framework in 2.0, removing some of the complexities that developers faced when implementing complex layouts in 1.x. See Details
• Grid
  The grid component has always been one of the centerpiece widgets in Ext, and with version 2.0 it has continued its evolution. New in this version is an even more polished user interface, improved performance, row grouping, summary rows, example custom plugins providing expandable rows and row numbering and much more. See Details
• XTemplate
  The Template class in 1.x works great for simple templates, but lacks some key features for creating more advanced output. In 2.0, a new XTemplate class has been added that provides sub-templates, array processing, inline code execution, conditional logic and much more. See Details
• DataView
  In 1.x, the View class provided templated data binding to generate customized UI views of data. The JsonView was a helper class for easily binding a template to JSON data. In 2.0, the capabilities of the View have been taken to the next level with DataView, which extends BoxComponent for easy addition to layouts and also supports the new XTemplate class for more powerful template processing. See Details
• Other New Components
  Several additional new components and widgets have been added in 2.0, including Action, CycleButton, Hidden (field), ProgressBar and TimeField. See Details

Additional Notes

• Themes
  The out-of-the-box theme support in 2.0 has been somewhat simplified. Ext supported four different themes in 1.x, but in 2.0 that number has been reduced to two ("Ext Blue" and Gray). The 'Vista' and 'Aero' themes have been removed. Custom themes can easily be added using the Gray theme's stylesheet as an implementation example, and some new 2.0 community themes are already available. While this is not an API change, it is a noteworthy change nonetheless that is worth mentioning.
• Breaking Changes
  Unfortunately, there are some changes in 2.0 that could not maintain backwards compatibility to 1.x. Because the underlying component and rendering models changed substantially, some existing components had to be rewritten in ways that were fundamentally incompatible with their 1.x counterparts. We have provided a 1.x to 2.0 Migration Guide that will hopefully ease the burden of upgrading an existing Ext 1.x application.

Component Model

Component Overview

One of the goals with 2.0 was to provide more basic building blocks. The Component class was originally introduced in 1.x, but was not fully integrated throughout the framework. In 2.0, Component's capabilities have been further expanded and improved upon, making it one of the most fundamental classes in the overall architecture. Component now provides a unified model for component creation, rendering, event handling, state management and destruction, and every component in Ext that requires these features now extends Component. Here are the key features of Component in 2.0:

• Explicit constructor chaining and overriding
  Component itself provides a base constructor that will apply any config passed into any subclass, and the initComponent function can be used all the way through the inheritance chain to provide custom constructor logic at each step in the hierarchy. Subclasses can safely assume that any configs will be applied properly and should implement any needed setup code in initComponent.
• Managed rendering
  In 2.0, every component automatically supports lazy (on-demand) rendering, and the rendering pipeline is managed for you automatically. Even so, you still have ultimate flexibility to customize the rendering process via the beforerender and render events.
• Managed destruction
  Each component also contains a destroy function, and Ext manages clean up by automatically garbage collecting and destroying components when they are no longer needed. Of course, destruction also provides beforedestroy and destroy events and can be handled when needed.
• Automatic state management
  Components now have built-in functionality for setting and retrieving state, and many components in Ext support automatic state management as long as the global StateManager has been initialized with a state Provider.
• Consistent interface for basic component behavior
  The most fundamental behaviors that can apply to any component such as hiding, showing, enabling and disabling are provided via Component, and these can all be overridden or customized by any subclass as needed.
• Availability via ComponentMgr
  Every component in Ext gets registered with the ComponentMgr on creation, so you can retrieve any component at any time simply by calling Ext.getCmp('id').
• Plugin support
  Any component can now be extended through the use of plugins. A plugin is any class with an init method that accepts a single parameter of type Ext.Component. Plugins can be added into any Component via the plugins config option. When a component is created, if any plugins are available, the component will call the init method on each plugin, passing a reference to itself. Each plugin can then call methods or respond to events on the Component as needed to provide its functionality.

Component Life Cycle

In general, the Component architecture in 2.0 will "just work." It's been designed to handle most of the management of components transparently to the end developer. However, there will come a time when something needs to be customized, or a Component needs to be extended. That's when a thorough understanding of the Component life cycle will become quite helpful. Following are the most important stages in the life cycle of every class based on Component:

Initialization

1. The config object is applied
   Classes that extend Component do not need to (and usually should not) provide a separate constructor. Component's constructor will not only apply any config passed into its subclasses, it also provides all of the following steps.
2. The base Component events are created
   These are events that can be fired by any Component, and they are enable, disable, beforeshow, show, beforehide, hide, beforerender, render, beforedestroy, destroy (see the Component API docs for complete details).
3. The component is registered in ComponentMgr
   As such it will always be available via Ext.getCmp.
4. The initComponent method is called
   This is the most important initialization step for subclasses, as this is a template method intended to be implemented by each subclass to provide any needed constructor logic. The class being created is called first, and each class in the hierarchy back up to Component is expected to call superclass.initComponent. This method makes it easy to implement and, if needed, override the constructor logic at any step in the hierarchy.
5. Plugins are loaded (if applicable)
   If this Component has any plugins specified in the config, they will be initialized at this time.
6. State is initialized (if applicable)
   If the Component is state-aware, its state will be reloaded if available.
7. The component is rendered (if applicable)
   The component is rendered immediately if either renderTo or applyTo is provided in the config, otherwise rendering is deferred until the Component is explicitly displayed in code or is told to render by its container.

Rendering

1. The beforerender event is fired
   This is a cancelable event, giving any handler the ability to prevent the Component from rendering if needed.
2. The container is set
   If no container is specified, the parent node of the Component's underlying DOM element is set as the container.
3. The onRender method is called
   This is the most important rendering step for subclasses, as this is a template method intended to be implemented by each subclass to provide the needed rendering logic. The class being created is called first, and each class in the hierarchy back up to Component is expected to call superclass.onRender. This method makes it easy to implement and, if needed, override the rendering logic at any step in the hierarchy.
4. The Component is "unhidden"
   By default, many components are hidden using special CSS classes like "x-hidden". If the autoShow config value is true, any "hide" classes are removed from the component at this time.
5. Custom class and/or style applied
   All Component subclasses support the special config properties of cls and style which are a custom, user-defined CSS class and rule respectively that will be applied to the DOM element underlying this Component. Specifying the cls value is the preferred method for visually customizing a Component and its constituent parts. Since the class will get applied to the topmost wrapper element of the Component's markup, any sub-elements of the Component can be adjusted using standard CSS inheritance rules.
6. The render event is fired
   This is a notification that the Component has been successfully rendered at this point. You can safely assume that its DOM elements are now available to your code if needed. If you attempt to access a Component prior to rendering, it won't be available and you'll get an error.
7. The afterRender method is called
   This is another template method for subclasses that can be implemented or overridden to provide any special post-rendering logic that may be needed. Each subclass is expected to call superclass.afterRender.
8. The Component is hidden and/or disabled (if applicable)
   The hidden and disabled config values are applied at this point.
9. Any state-specific events are initialized (if applicable)
   State-aware Components can declare special events that are specific to loading and saving state. If supplied, any such events will be added.

Destruction

1. The beforedestroy event is fired
   This is a cancelable event, giving any handler the ability to prevent the Component from being destroyed if needed.
2. The beforeDestroy method is called
   This is another template method that can be implemented or overridden to provide any special pre-destruction logic that may be needed. Each subclass is expected to call superclass.beforeDestroy.
3. Element and its listeners are removed
   If the Component has been rendered, its underlying Element's event listeners are removed and the Element itself is then removed from the DOM.
4. The onDestroy method is called
   This is another template method that can be implemented or overridden to provide any special post-destruction logic that may be needed. Each subclass is expected to call superclass.onDestroy. Note that the Container class (and any Container subclasses) provides a default implementation of onDestroy that automatically loops through its items collection and calls destroy on each child Component recursively.
5. Component is unregistered from ComponentMgr
   It will no longer be available via Ext.getCmp.
6. The destroy event is fired
   This is simply a notification that the Component has been successfully destroyed at this point and is no longer available in the DOM.
7. Event listeners on the Component are removed
   The Component itself can have event listeners separately from its underlying Element. If any exist, they are removed.

Component XTypes

A new concept in 2.0 is that of xtypes, or Ext-specific component types. The available xtypes are summarized in the header of the Component class API. XTypes can be used similarly to regular JavaScript object types to look up or compare Components by type using methods like isXType and getXType. You can also list the xtype hierarchy of any Component using getXTypes.

However, the real power of XTypes is how they can be used to optimize Component creation and rendering. Any Component can be created implicitly as an object config with an xtype specified, allowing it to be declared and passed into the rendering pipeline without actually being instantiated as an object. Not only is rendering deferred, but the actual creation of the object itself is also deferred, saving memory and resources until they are actually needed. In complex, nested layouts containing many Components, this can make a noticeable improvement in performance.

//Explicit creation of contained Components:
var panel = new Ext.Panel({
   ...
   items: [
      new Ext.Button({
         text: 'OK'
      })
   ]
};
 
//Implicit creation using xtype:
var panel = new Ext.Panel({
   ...
   items: [{
      xtype: 'button',
      text: 'OK'
   }]
};

In the first example, the button will always be created immediately during the panel's initialization. With many added Components, this approach could potentially slow the rendering of the page. In the second example, the button will not be created or rendered until the panel is actually displayed in the browser. If the panel is never displayed (for example, if it is a tab that remains hidden) then the button will never be created and will never consume any resources whatsoever.

BoxComponent

While not new to 2.0, BoxComponent is another critical foundation class that extends Component and provides a consistent, cross-browser box model implementation for any component that will be visually rendered and can participate in layouts. BoxComponent transparently handles sizing and positioning, automatically dealing with any browser-specific differences in padding, margins and borders to produce a consistent box model across every supported browser. All container classes in 2.0 extend BoxComponent.

Container Model

Container

Container is the most basic foundation for any component that will contain other components. It provides the layout and rendering logic needed for handling sizing and nesting of other components, and also provides the basic mechanism for consistently adding components to the container. The Container class should never need to be used directly, but is intended as the base class for all visual container components.

Panel

Panel is the workhorse container in 2.0, and will be what you use for 90% of your layout tasks. At its most basic, a Panel can be a completely non-visual box used for constructing layouts. However, Panel also provides the basic building blocks needed in an application UI window, including bottom and top bars for adding toolbars and menus, a header, footer and body. It also provides built-in expandable and collapsible behavior and tool buttons, as well as pre-built buttons for a variety of other tools. Panels can be easily dropped into any Container or layout, and the layout and rendering logic are completely managed by Ext.

The following Panel subclasses are primary widgets in Ext 2.0:

• GridPanel
• TabPanel
• TreePanel
• FormPanel

Window

Window is a specialized Panel that also can be floated, minimized/maximized, restored, dragged, etc. It is intended as the foundation class for desktop-like windowed application UIs as can be seen in the Ext Desktop Demo.

Viewport

The Viewport is a utility container class that automatically renders to the document body and sizes itself to the dimensions of the browser viewport. This is a handy shortcut for creating full-screen applications as browser resizing and layout recalculations are managed for you automatically. Note that the Viewport cannot be rendered to any container other than document.body, and as such, you can only use one Viewport instance per page.

Layouts

Introduction

One of the most significant areas of improvement in 2.0 is the ease and flexibility with which you can create sophisticated application layouts. In Ext 1.x, layout development was centered around the BorderLayout, Region and ContentPanel classes. While the 1.x BorderLayout made it extremely easy to generate attractive UIs, it did not provide enough building blocks to allow truly custom layout creation. Creating complex layouts often required some manual coding to deal with scroll bars, nesting issues and other quirks.

Ext 2.0 has delivered a completely revamped, enterprise-level layout management system. There are now 10 separate layout managers, providing the foundation for building just about any possible style of application layout. Layouts are also managed by Ext so that size, position, scroll and other attributes simply work as expected, right out of the box. You can mix and match different containers, each with a different layout, nesting to any level you want, and it's a snap.

Layouts are not intended to be created directly via the new keyword. Instead, they are created and used internally by the container classes. Containers themselves know nothing about layout — they simply delegate layout duties to whichever layout class has been specified during their configuration. Anytime you create a container, you can specify its layout style and configure any options that are specific to the layout class via the layoutConfig property. For example:

var panel = new Panel({
    title: 'My Accordion',
    layout: 'accordion',  // The layout style to use in this panel
    layoutConfig: {
        animate: true     // Layout-specific config values go here
    }
    // additional Panel options...
});

It is also important to understand that when you create nested layouts, with Panels containing other Panels, every Panel in the layout must have a layout specified. In most cases when you don't need a specific layout style like 'border' or 'accordion,' you will probably want to specify 'fit' as it will still manage the base sizing of the Panel for you within its container. If you do not specify a layout, the default ContainerLayout class will take over so that the application will still work. However, in most real world cases, the resulting behavior will not be what is expected without an explicit layout.

Each layout class supports its own specific config options. Be sure to reference the API docs for each layout for more information.

Layout Managers

	ContainerLayout This is the base class for all other layout managers, and the default layout for containers when a specific layout is not defined. ContainerLayout has no visual representation — it simply manages contained items, rendering them when needed and handling basic duties like resize buffering. ContainerLayout should not generally be created directly, although it can be extended to create custom layouts. See the API reference.		CardLayout CardLayout is a specific layout used in cases where a container holds multiple elements, but only a single item can be visible at any given time. Most commonly, this layout style is used for wizards, custom tab implementations, or any other use case requiring multiple, mutually-exclusive pages of information. See the API reference.
	AbsoluteLayout This is a very simple layout that allows you to position contained items precisely via X/Y coordinates relative to the container. See the API reference.		ColumnLayout This is the layout style of choice for creating structural layouts in a multi-column format where the width of each column can be specified as a percentage or pixel width, but the height is allowed to vary based on content. See the API reference.
	AccordionLayout The AccordionLayout contains a set of vertically-stacked panels that can be expanded and collapsed to display content. Only one panel can be open at a time. See the API reference.		FitLayout This is a simple layout style that fits a single contained item to the exact dimensions of the container. This is usually the best default layout to use within containers when no other specific layout style is called for. See the API reference.
	AnchorLayout This layout is for anchoring elements relative to the sides of the container. The elements can be anchored by percentage or by offsets from the edges, and it also supports a virtual layout canvas that can have different dimensions than the physical container. See the API reference.		FormLayout The FormLayout is a utility layout specifically designed for creating data entry forms. Note that, in general, you will likely want to use a FormPanel rather than a regular Panel with layout:'form' since FormPanels also provide automatic form submission handling. FormPanels must use layout:'form' (this cannot be changed), so forms needing additional layout styles should use nested Panels to provide them. See the API reference.
	BorderLayout This is the exact same layout style as BorderLayout in 1.x — layout regions with built-in support for nesting, sliding panels open and closed and splitters separating regions. This is the most common layout style for the primary UI in typical business applications. See the API reference.		TableLayout This layout style generates standard HTML table markup with support for column and row spanning. See the API reference.

Grid

Overview

The grid UI is actually implemented by the GridView class, and in 2.0 the GridView has been greatly improved. Major new features in the 2.0 GridView include:

• Improved performance
  The underlying structure and rendering code for GridView have been completely refactored in 2.0 with performance as the first priority. As part of that priority, the column locking feature was removed (see next section).
• Improved look and feel
  Along with the new 2.0 themes, the grid has received a face lift as well, making it even sleeker and more visually attractive than before.
• Single-level row grouping
  Rows can now be grouped on a given column, and regrouped by the user dynamically.
• Group summary rows
  Each group of rows can also have an optional summary row for summarizing the data in the group.
• Advanced plugin support
  In 2.0, plugin support in general is new. The GridView in particular uses the new plugin architecture to great effect, shipping with several pre-made plugins as examples. The RowExpander plugin provides expandable/collapsible rows that each include a spanning row body, and the RowNumberer plugin provides simple row numbering support.

A Note About Column Locking

Some may notice that the column locking feature, introduced in Ext 1.x, has been removed in 2.0 and will no longer be supported. Column locking, while useful for a small subset of users, was not compatible with many of the new features implemented in the 2.0 GridView (e.g. grouping, summaries, etc) and led to decreased performance for everyone due to the way the grid had to be rendered in order to support locking. It might be possible to port the 1.x GridView forward to 2.0, or to patch the 2.0 GridView to support it, but this will not be done officially by the Ext team.

Note: There is an effort currently underway in the community to implement column locking via a user extension for 2.0, and it is already looking pretty promising as of this writing. More information is available in the forum thread.

XTemplate

XTemplate provides a variety of built-in tags and special operators to support extremely robust template processing using complex data structures. Here is the high-level list of supported features — for complete details and usage examples, please see the XTemplate API docs.

• Auto filling of arrays and scope switching
• Access to parent object from within sub-template scope
• Array item index variable
• Basic math operator support on data values
• Auto-rendering of flat arrays (containing non-object values)
• Basic conditional logic using if
• Ability to execute arbitrary inline code within the template
• Support for template config properties
• Custom template methods via the config object

DataView

On the surface, DataView is very similar to the 1.x View class. Both support templated data rendering, both are bound to data stores and both have built-in selection models and events. However, the DataView is a huge step forward as it leverages the full power of the new 2.0 architecture. Here are the most significant changes:

• Extends BoxComponent
  The 1.x View class extended Observable, meaning that while it worked great as an independent component, it had no built-in capabilities for participating in layouts with other components. DataView, on the other hand, extends BoxComponent. As discussed above, this provides many advantages, including the managed life cycle of Component and the layout capabilities of BoxComponent.
• Leverages XTemplate
  The 1.x View class used the 1.x Template class internally for its template processing. This worked fine for relatively simple views, but lacked the power to handle complex rendering tasks. DataView uses the 2.0 XTemplate class for its template processing. As discussed above, this provides a much more powerful template engine and enables DataView to render complex data into a custom UI with ease.
• Additional config options
  DataView provides even more flexibility, with the following new configs:
  • itemSelector: DataView requires a DomQuery selector to tell it how to identify each item in the view. This provides increased flexibility and speed compared to 1.x.
  • simpleSelect: This is a new selection mode option that enables multi-selection by clicking on multiple items without requiring the user to hold Shift or Ctrl.
  • overClass: A CSS class that gets automatically applied to each element on mouseover and removed on mouseout.
  • loadingText: DataView supports the same standard automatic loading mask functionality as other components in Ext that are bound to stores.

Other New Components

Several interesting new components and widgets have been added in 2.0. Make sure you have a look at their API documentation for complete details on what each component has to offer.

Action

An Action is a piece of reusable functionality that can be abstracted out of any particular component so that it can be usefully shared among multiple components. Actions let you share handlers, configuration options and UI updates across any components that support the Action interface (primarily Toolbar, Button and Menu components). See the API Reference.

CycleButton

This is a specialized SplitButton implementation that contains a menu of CheckItem elements. The button automatically cycles through each menu item on click, raising the button's change event (or calling the button's changeHandler function, if supplied) for the active menu item. An example can be seen in the FeedViewer demo application — the button that sets the preview window location is a CycleButton. API Reference.

Hidden (field)

This is simply a convenience field that renders as a standard HTML hidden input field. This is quite useful for storing hidden values to submit with the form, and in 2.0 hidden fields can be created and manipulated just like other Ext form components. See the API Reference.

ProgressBar

There was a simple progress bar built into the MessageBox class in 1.x. Now it has been factored out into a separate widget and further improved. It supports two different modes (manual and automatic progress) and the look and feel can be easily customized. See the API Reference.

TimeField

This is a simple time picker dropdown implementation. See the API Reference.