+# Ext JS 4 Upgrade Guide
+
+Ext 4 is a revolutionary step forward in web app development. Almost every
+major component within the framework has been improved, in many cases
+drastically so. There are also many components and subsystems that are brand
+new since Ext 3. This guide will provide an introduction to all major changes
+between Ext 3 and 4.
+
+If you find any issues in this document or would like to provide feedback,
+please visit the [Ext 3 to 4 Migration][2] thread in the Sencha forums.
+
+## General
+
+These changes apply across both Ext Core and Ext JS.
+
+### Ext 3 Compatibility
+
+Ext 4 is by far the most comprehensive update to Ext JS that we've ever
+produced, and many changes were required that are not compatible with Ext 3.
+However, we've gone to great lengths to provide as much backwards-
+compatibility as possible.
+
+#### JS Compatibility Layer
+
+This is an optional JavaScript file that can be referenced after Ext 4 is
+loaded that will provide the aliases and overrides necessary to make the vast
+majority of Ext 3 code run correctly under Ext 4 as-is.
+
+You can download the Ext JS 3 to 4 Migration Pack from the 'Related Downloads'
+section of the [Ext JS Download page](http://www.sencha.com/products/extjs/download/)
+
+#### Sandbox Mode
+
+Ext 4 has introduced changes that now make it possible to completely sandbox
+previous versions of the framework alongside Ext 4 within the same page. On
+the JavaScript side, this is possible with the removal of all prototypal
+enhancements to core JavaScript objects in Ext 4. Now you can simply alias the
+global Ext object to a different name and be completely isolated from previous
+Ext versions.
+
+On the markup/CSS side of things, Ext 4 now uses CSS generated from templates
+using Compass & SASS, so it is trivial to customize the prefix of all CSS
+rules defined by the framework. Combined with the new Ext.baseCSSPrefix
+property, it is now extremely easy to isolate markup generated from multiple
+versions of Ext on a single page.
+
+### Package & Namespace Updates
+
+All classes and packages have been restructured according to a strict naming
+convention. This makes classes more consistent and easier to find. For
+example, in Ext 3 classes like Button, CycleButton and SplitButton are simply
+grouped under /widgets (along with many other classes). The classes are also
+defined directly on the global Ext object.
+
+In Ext 4, every class has been consistently placed into packages and
+namespaces based on related functionality. This is not entirely new, but was
+never consistently enforced in Ext 3. Back to the Button example above, in Ext
+4 these classes are now:
+
+ - Grouped into a single src/button/ package at the file level
+ - Grouped into a new Ext.button namespace in code
+ - Renamed based on the new namspaces (e.g., Ext.SplitButton -> Ext.button.Split)
+
+All classes that were reorganized are still available via the new
+alternateClassName property, so Ext 3 classnames will still work under Ext 4
+if necessary (e.g. alternateClassName: 'Ext.SplitButton'). _Going forward with
+Ext 4 development it's recommended that you migrate to the new conventions in
+your own code_.
+
+## Ext Core
+
+### New Class System
+
+#### Resources
+
+[Overview blog post & demo][5]
+
+Ext of course is already built on a powerful prototype-based class system,
+which approximates a traditional OO-based class system. In Ext 4 we've taken
+our class system to a new level of flexibility with the addition of many key
+features, and best of all the changes are 100% backwards-compatible with the
+Ext 3 class system. The main new features are:
+
+ - Ext.define to create class definitions within the new system
+ - Automatic dependency management and dynamic class loading
+ - Mixins
+ - Statics
+ - New config option for Automatic setter / getter generation
+
+{@img ext4-class-system.jpg Ext 4 Class System}
+
+#### Class Definition
+
+You can still use the tried and true new ClassName() syntax in Ext 4, but the
+preferred syntax going forward is to use the new Ext.define function to define
+new classes. By defining classes explicitly within the Ext class system all of
+the additional class features in the following sections become enabled. The
+new keyword will still work, but without those benefits.
+
+An additional benefit of using Ext.define is that it will automatically detect
+and create new namespaces as needed, without the need for explicitly defining
+the namespaces separately from declaring the classes that use them.
+
+Here's a simple example of the old and new syntax for how you would define a
+custom class that extends an existing Ext component:
+
+ // Ext 3:
+ Ext.ns('MyApp'); // required in Ext 3
+ MyApp.CustomerPanel = Ext.extend(Ext.Panel, {
+ // etc.
+ });
+
+ // Ext 4
+ Ext.define('MyApp.CustomerPanel', {
+ extend: 'Ext.panel.Panel',
+ // etc.
+ });
+
+#### Class Loading
+
+Ext 4 now includes a robust dynamic class loading system that also provides
+integrated dependency management. Again, this is an optional feature, but
+provides a couple of key benefits:
+
+ - **Dynamic loading**:
+ Classes can be loaded dynamically and asynchronously at runtime simply
+ based on the dependency tree that Ext manages internally. This means that
+ you can stop managing brittle blocks of manual include tags in HTML pages
+ and simply let the class loader figure out what your page needs to run.
+ This is mostly useful in the development environment when dependency
+ flexibility is more important than page load speed.
+
+ - **Dynamic build generation**:
+ For production, it's usually preferable still to compile down to a single
+ (or few) build files. Since Ext now understands the entire dependency
+ graph at runtime, it can easily output that graph as needed (for example,
+ in the form of a custom build configuration). And even more importantly,
+ this capability is not restricted to the Ext namespace. You can include any
+ number of custom classes and namespaces in addition to Ext and as long as
+ everything is defined using the class system Ext will be able to figure out
+ how they all relate. In the very near future, any Ext developer will have
+ one-click custom build capability that automatically manages the entire
+ Ext + custom application class graph, even as it changes from one minute
+ to the next, and only builds _exactly_ what's actually needed by the app.
+
+This dynamic loading is enabled simply by using Ext.define and by defining the
+dependencies in code using two new class properties:
+
+ - requires: The class dependencies required for a class to work. These are guaranteed to be loaded prior to the current class being instantiated.
+ - uses: Optional class dependencies that are used by, but not required by, a class. These can be loaded asynchronously and do not have to be available for the class to be instantiated.
+
+#### Mixins
+
+This is a new approach to plugging custom functionality into existing classes.
+The new mixins config, included during instantiation of a class, allows you to
+"mix in" new capabilities to the class prototype. This is similar to the
+existing Ext.override function, although it does not replace existing methods
+like override does, it simply augments the prototype with whatever is new.
+Example syntax:
+
+ Ext.define('Sample.Musician', {
+ extend: 'Sample.Person',
+
+ mixins: {
+ guitar: 'Sample.ability.CanPlayGuitar',
+ compose: 'Sample.ability.CanComposeSongs',
+ sing: 'Sample.ability.CanSing'
+ }
+ });
+
+#### Statics
+
+Any class can now define static methods simply by defining them in its statics
+class property.
+
+#### Config
+
+In Ext we currently use the term **config** to mean any properties on a class
+prototype that, by convention, make up its configurable API and can be set by
+calling code. While this is still true in Ext 4, there is also a new optional
+config that's actually called config. When configuration properties are added
+to the config property, it will automatically generate a getter, setter, reset
+and apply (template method for custom setter logic) methods matching that
+property. For example, given this code:
+
+ Ext.define('MyClass', {
+ config: {
+ title: 'Default Title'
+ }
+ });
+
+...the following methods will get generated automatically behind the scenes:
+
+ title: 'Default Title',
+
+ getTitle: function() {
+ return this.title;
+ },
+
+ resetTitle: function() {
+ this.setTitle('Default Title');
+ },
+
+ setTitle: function(newTitle) {
+ this.title = this.applyTitle(newTitle) || newTitle;
+ },
+
+ applyTitle: function(newTitle) {
+ // custom code here
+ // e.g. Ext.get('titleEl').update(newTitle);
+ }
+
+### Env Namespace
+
+Provides access to comprehensive information about the host browser and
+operating system, as well as a complete list of modern browser feature
+detection.
+
+#### Ext.env.Browser
+
+This class provides all of the browser metadata (name, engine, version,
+isStrict, etc.) that used to exist directly on the global Ext object.
+
+#### Ext.env.FeatureDetector
+
+This is a brand new class whose functionality did not exist in Ext 3. It
+provides properties detailing the feature capabilities of the running host
+environment, primarily to detect the availability of modern HTML5 and CSS3
+features, as well as mobile features, including:
+
+ - CSS transforms / animations / transitions
+ - SVG / VML
+ - Touch availability / Orientation
+ - Geolocation
+ - SqlDatabase
+ - Websockets
+ - History
+ - Audio
+ - Video
+
+#### Ext.env.OS
+
+Identifies the current host operating system, and includes a more
+comprehensive list than Ext 3 did (adding various mobile OS'es).
+
+### Lang Package
+
+Much of the functionality within this new package existed under Ext 3, but as
+modifications to core JavaScript object prototypes. While this was convenient,
+it made it very challenging for Ext to coexist with other frameworks that
+modified the same objects. It also meant that Ext was directly exposed to any
+changes that might occur in the ECMAscript specification going forward. To
+remedy these problems we've completely removed all core JavaScript object
+modifications and placed them all into appropriately namespaced static classes
+under the Ext object.
+
+All of the Prototype enhancements to the following objects have been moved
+accordingly (note that there is not actually a lang _namespace_ -- it's just
+the package that holds these new files in the source tree):
+
+ - Array -> Ext.Array
+ - Date -> Ext.Date
+ - Function -> Ext.Function
+ - Number -> Ext.Number
+ - Object -> Ext.Object
+ - String -> Ext.String
+
+Note that these will all be aliased back to the core object prototypes in the
+compatibility file, but in order to fully move to Ext 4 and remove the extra
+compatibility layer the usage of any of the Ext 3 versions of these functions
+will ultimately have to be updated to the new namespaced versions.
+
+#### Ext.Function
+
+There are a few noteworthy changes to how the base Function prototype methods
+have been implemented in Ext 4. Most importantly, the Function.createDelegate
+and Function.createCallback methods are now named Ext.Function.bind and
+Ext.Function.pass respectively. Likewise, Function.defer is now available as
+Ext.Function.defer. Because these three functions are so commonly used, they
+are also aliased directly onto the Ext object as Ext.bind, Ext.pass and
+Ext.defer.
+
+The other Function methods like createSequence and createInterceptor have also
+been moved to Ext.Function, and there are also a few new useful additions like
+createBuffered and createThrottled.
+
+Here are some examples of how the invocation syntax has changed:
+
+ // Ext 3:
+ myFunction.createDelegate(this, [arg1, arg2]);
+ myFunction.defer(1000, this);
+
+ // Ext 4:
+ Ext.bind(myFunction, this, [arg1, arg2];
+ Ext.defer(myFunction, 1000, this);
+
+## Ext JS
+
+#### Resources
+
+ - [Intro to Ext 4 (video)][7]
+ - [Ext 4 Architecture (video)][8]
+
+### General
+
+#### Adapters
+
+In previous versions of Ext through version 3 we supported the use of third-
+party base libraries via adapters. As of Ext 4 this support has been
+discontinued. Moving forward, Ext Core will be the required foundation for all
+Ext JS applications. Of course third party libraries may still be optionally
+used _in addition to_ Ext Core (and in fact this will even work better now
+that JavaScript object modifications have been removed from Ext), but
+they will no longer be supported as base library _dependencies_ for Ext.
+
+#### ARIA
+
+Ext 4 features a new level of accessibility with full ARIA support baked right
+into every component in the framework. Ext.Component now has a config property
+called ariaRole which defaults to "presentation" (meaning the role is simply
+visual and provides no user interaction functionality) but can be easily
+overridden as needed. For example, Ext.button.Button overrides the default
+with ariaRole:'button'. This renders the standard role HTML attribute into the
+wrapping markup tag and tells screen readers that the contained markup (no
+matter how complex) functionally represents an action button. This is hugely
+important for accessibility and is now implemented throughout Ext.
+
+Another important ARIA hint that is built into Ext.Component is automatic
+adding/removing of the standard aria-disabled HTML attribute to signify the
+enabled state of functional UI elements to screen readers.
+
+### Data
+
+The data package has seen a significant upgrade since 3.x. Data is one of the
+many packages that Ext 4 now shares with Sencha Touch, and there is already a
+huge amount of information about it available today. Here are a few of the
+articles that give some background on the new capabilities -- we strongly
+suggest reading at least the first one before diving into code:
+
+#### Resources
+
+ - [Ext 4 Data Overview (blog post)][10]
+ - [Models (blog post)][11]
+ - [Proxies (blog post)][12]
+ - [Validations & Associations (blog post)][13]
+
+#### Overview
+
+Most of the changes in the data package are non-breaking when including the
+Ext 3 compatibility file. The biggest updates have come to Store, Proxy and
+Model, which is the new name for Record:
+
+ - **Store** no longer cares about the format of the data (e.g. no need for
+ JsonStore, XmlStore and other store subclasses). It now delegates all of
+ its loading and saving to the attached Proxy, which now receives the
+ Reader and Writer instances. Store can also perform multi sorting,
+ filtering and grouping dynamically on the client side, and can
+ synchronize itself with your server
+
+ - **Proxy** can now be attached to either a Store or [directly to a Model][14],
+ which makes it easy to manipulate data without a Store. Proxies can be
+ configured with Readers and Writers which decode and encode communications
+ with your server.
+
+ - **Model** is a much more capable version of Record, adding support for
+ [associations, validations and much more][14].
+
+Ext JS 4 also features the brand new LocalStorageProxy which seamlessly
+persists your Model data into HTML5 localStorage.
+
+### Draw
+
+This package is entirely new and has no Ext 3 analog. This is an entire
+library that provides custom drawing capabilities by abstracting the standard
+SVG and VML engines, choosing the best one available at runtime based on the
+current browser. This package provides the foundation for the new
+charting package in Ext 4, but can also easily be used for any type of
+custom drawing and graphics needs. Here are the major features:
+
+ - HTML5 standards based
+ - Rendering of primitive shapes, text, images, gradients
+ - Library classes for manipulating color, matrix transformations, etc.
+ - Ext.draw.DrawComponent
+
+ - Extends Ext.Component
+ - Engine preference via feature detection
+ - Customizable engine preference order
+ - Layout participation
+
+ - Built-in sprite management via Ext.draw.Sprite
+
+ - Abstracted drawing elements
+ - Normalizes differences between engine API syntax
+ - Attributes
+ - Event support (extends Observable)
+ - Transforms (Rotate, Translate, Scale)
+ - Animation supported through Ext.fx
+ - SpriteComposites
+
+### Charting & Visualization
+
+Charting in Ext 4 is a huge step forward from Ext 3, which did support
+charting, but only Flash-based. In Ext 4 we've completely removed Flash from
+the picture, yet retained complete best-of-breed browser support (all the way
+back to IE6) using Canvas, SVG and VML. The charting engine automatically
+selects the best engine for the current platform at runtime, and everything is
+rendered uniformly and with the best possible performance across all supported
+browsers. More importantly, all charting functions share a single uniform API,
+regardless of the underlying charting engine in use.
+
+#### Resources
+
+ - [SenchaCon Overview (video)][16]
+ - [SenchaCon Overview (slides)][17]
+ - {@img working-with-charts.gif Working with Charts}
+
+### Fx
+
+In Ext 3, the Fx class mainly provided a set of useful Element effects (slide,
+highlight, fade, etc.). In Ext 4 this basic functionality has been retained,
+but there is an entire Fx package that goes far beyond simple element effects.
+
+There's now an underlying Animator class that coordinates multiple animations
+concurrently running on the page.
+
+Components may now be animated in size and position via new Fx "target"
+classes (Ext.fx.target.*), which opens up many new possibilities for creating
+dynamic UI's.
+
+### Layout
+
+#### Resources
+
+ - [Ext 4 Layouts (video)][19]
+ - [Ext 4 Layouts (slides)][20]
+
+#### ComponentLayout
+
+Complex components use the new ComponentLayout (as opposed to ContainerLayout,
+the new name for the traditional Container-based layouts carried over from Ext
+3) to perform sizing of internal elements in response to resize calls. An
+example of this is the FieldLayout which manages the size and position of both
+an associated label and input element within the containing Field Component.
+
+#### FormLayout
+
+As of Ext 4, FormLayout is no longer available. See Layout in the Form
+section later in this document for details.
+
+#### BorderLayout
+
+Border layout in Ext 4 is fully backwards-compatible to Ext 3.
+
+Panel Headers now may be orientated vertically, so east and west regions are
+replaced on collapse by a vertical header (a full-fledged Ext.panel.Header
+instance, unlike the simple Element in Ext 3) containing the title rotated by
+90 degrees (courtesy of Ext 4's new Draw package). The placeholder
+Header is accessible using the layout's new getPlaceholder method. The
+placeholder Component is not rendered until the Panel is first collapsed. All
+the methods of the Ext.panel.Header class are available on it. As a Container
+subclass, it also inherits all the methods of Container.
+
+Another small difference is that the cmargins config is no longer supported.
+The placeholder Header now has the same margins that the expanded Panel did.
+This makes it easier to create layouts which look good in both collapsed and
+expanded states by default.
+
+Internally, the BorderLayout class now uses nested HBox and VBox layouts to
+create the bordered arrangement, making the layout much more flexible and
+customizable than it has ever been.
+
+### Component
+
+Any Component subclass may now be configured as floatable using the
+floating:true config to specify that it floats above the document flow.
+Floating components may be configured as draggable and/or resizable using the
+standard configs. They may also be added as child items to any container, in
+which case they will not participate in the container's layout, but will float
+above it.
+
+All floating Components now have their z-index managed by a ZIndexManager.
+This is the successor to the Ext 3 WindowGroup class. By default, floating
+components (such as Windows) which are rendered into the document body by
+having their show method called are managed by the singleton
+Ext.WindowManager. All floating components therefore have a `toFront` and
+toBack method which invokes the ZIndexManager.
+
+Floating components which are added to a specific Container acquire a
+ZIndexManager reference at render time. They search for an ancestor Container
+from which to request z-index management. Usually, this will be provided by
+the singleton Ext.WindowManager, but if the floating component is the
+descendant of a floating **Container** such as a Window, that Window will
+create its own ZIndexManager instance, and all floating Components within will
+be managed relative to the Window's z-index.
+
+This is a huge improvement over previous versions of Ext, in which complex
+arrangements of floated containers could quickly lead to z-index conflicts
+among different components. Now, for example, the dropdowns of combo boxes
+that are contained in a window will _always_ be correctly managed above that
+window.
+
+### Form
+
+#### Layout
+
+In Ext 3 the FormPanel used the FormLayout class for positioning field labels,
+input boxes, error indicators, etc. In Ext 4 FormLayout has been removed
+entirely, in favor of using standard layouts for overall arrangement and the
+new FieldLayout (one of the new ComponentLayout classes) for the field
+labels etc. This makes it now possible to use any kind of standard layouts
+within any form, making the creation of custom form layouts exceedingly simple
+compared to Ext 3.
+
+The default container layout for FormPanel is now anchor, although any
+standard layout may now be used within forms.
+
+#### FieldContainer
+
+Ext4 also introduces a new class for managing form layouts:
+Ext.form.FieldContainer. This is a standard Ext.Container which has been
+enhanced to allow addition of a label and/or an error message, using all the
+same configurations regarding label and error placement that are supported by
+Ext.form.Labelable. The container's children will be confined to the same
+space as the field input would occupy in a real Field. This makes it easy to
+add any group of arbitrary components to a form and have them line up exactly
+with the form's fields.
+
+#### Field as Mixin
+
+One longstanding difficulty with Ext has been adding non-Field components into
+a form with field-like capabilities like layout, validation, value management,
+etc. The only way to easily inherit field behavior in Ext 3 was to subclass
+Ext.form.Field directly, but in reality many components must subclass
+something outside of the Field class hiearchy. Since Ext (and JavaScript) has
+no support for true multiple inheritance, the result is normally copying most
+if Field's code directly into the custom class, which is non-optimal to say
+the least.
+
+Now that Ext 4 supports mixins as part of its updated class system, this
+is no longer an issue. Field can now be used as a mixin to any other
+component, making it simple to provide full Field API support to almost
+anything. And of course you can easily override methods as needed if the
+default Field behavior needs to be customized (it is common to override
+getValue and setValue for example).
+
+#### Validation
+
+A common desire when building forms is to give the user feedback on the
+validity of fields as immediately as possible, as the user is entering data.
+While this could be done in Ext 3, it was clumsy and required using the
+monitorValid option on FormPanel which was non-optimal for performance because
+it invoked full-form validation several times per second.
+
+In Ext 4 we have reworked form validation to make immediate feedback more
+elegant and performant. This is enabled mainly by implementing a new event
+flow:
+
+ - Input fields now listen to a set of modern browser events that allow us
+ to detect changes immediately as the user makes them via any possible
+ method, including typing, cutting/pasting, and dragging text into the
+ field. We handle these events and roll them up together, firing the
+ field's changeevent when a change in its value is observed (discussed
+ further below).
+ - Each field validates itself when its value changes. When its validity
+ changes from valid to invalid or vice-versa, it fires a new
+ validitychange event.
+ - When any of the validitychange events fired by the fields causes the
+ overall validity of the enclosing form to change, the BasicForm fires
+ a validitychange event of its own.
+
+This new event flow allows for immediate feedback to users regarding the
+validity of the form, and because it is based on events rather than polling,
+performance is excellent. Therefore, this is now the default behavior (it had
+to be enabled explicitly in Ext 3), though it can of course be easily
+disabled.
+
+There are still situations, however, in which polling may still be useful.
+Some browsers (notably Opera and older versions of Safari) do not always fire
+events when fields are edited in certain ways such as cutting/pasting via the
+context menu. To handle these edge cases, you can use the new pollForChanges
+config on FormPanel to set up interval polling for changes to field values;
+this triggers the same event flow above. While polling is still not great for
+performance, this is less intensive than Ext 3's polling because it only
+checks for value changes, rather than forcing validation (and therefore value
+parsing, conversion, and pattern matching) each time.
+
+The validation of each field is now triggered when a change in the field's
+value is detected (assuming the validateOnChange config is left enabled). The
+browser events used to detect value changes are defined by the
+checkChangeEvents config, and are set to the following by default:
+
+ - change and propertychange for Internet Explorer
+ - change, input, textInput, keyup, and dragdrop for all other browsers
+
+This set of events successfully detects nearly all user-initiated changes
+across the set of supported browsers. The only known exceptions at the time of
+writing are:
+
+ - Safari 3.2 and older: cut/paste in textareas via the context menu, and
+ dragging text into textareas
+ - Opera 10 and 11: dragging text into text fields and textareas, and cut
+ via the context menu in text fields and textareas
+ - Opera 9: Same as Opera 10 and 11, plus paste from context menu in text
+ fields and textareas
+
+If you must absolutely ensure that changes triggered by the above actions also
+trigger validation, you can use FormPanel's pollForChanges and pollInterval
+configs, and/or startPolling and stopPolling methods to check for changes on a
+timer.
+
+Ext 3 supported the formBind property on buttons added to the form via the
+buttons property, which allows them to be automatically enabled/disabled as
+the form's validity changes. In Ext 4, this has been expanded so that formBind
+may be specified on _any component_ that is added anywhere in the FormPanel.
+
+#### FieldDefaults
+
+One time-saving feature of the old Ext 3 FormLayout was that it allowed
+developers to configure the layout of all fields within the form from a single
+config, using the hideLabels, labelAlign, etc. config properties of FormPanel.
+Since Ext 4 now uses the standard layouts for form containers, it would be
+much less convenient to have to specify common field layout properties again
+and again for each field or container. Therefore FormPanel now has a
+fieldDefaults config object, which specifies values that will be used as
+default configs for all fields at any depth within the FormPanel.
+
+#### BasicForm
+
+While BasicForm was most often limited to internal use by FormPanel in Ext 3,
+it has been refactored in Ext 4 to make it more flexible and more easily
+extended. It no longer requires its associated container to provide a `<form>`
+element around all the fields, and does not require its container to manually
+notify the BasicForm when adding or removing fields. It is therefore now
+completely decoupled from FormPanel, and can potentially be used to manage
+form fields within any Container.
+
+### Grid
+
+The grid components have been rewritten from the ground up for Ext 4. While
+this was for good reason and the benefits will be well worth it, unfortunately
+this is one of the areas in Ext 4 where full backwards compatibility could not
+be practically maintained. A complete migration guide will be provided to
+assist with the transition from Ext 3 to 4 grids.
+
+#### Intelligent Rendering
+
+Ext 3's grid works fantastically well, but takes the "least common
+denominator" approach to its rich feature support by always generating the
+full markup needed by every grid feature (which is overly-heavy in most
+cases). Ext 4 takes a much more intelligent approach to this problem. The
+default basic grid has very lightweight markup, and only as developers enable
+different features will the additional feature-specific markup be rendered.
+This is a huge boost both for page rendering speed and overall grid
+performance.
+
+#### Standardized Layout
+
+Along with a smarter rendering pipeline, many portions of the new grid have
+been made into proper Components and integrated into the standard layout
+management system rather than relying on custom internal markup and CSS. This
+enables us to unify grid's rendering process with the rest of the framework,
+while still retaining a pixel-perfect UI experience.
+
+One useful example of this is the new HeaderContainer class. In Ext 3 column
+headers were baked into the grid and not very customizable. In Ext 4 the
+column headers are true Containers and now use a standard HBox layout,
+allowing you to do things like provide custom flex values per column.
+
+#### Feature Support
+
+In Ext 3, it was easy to add new functionality to grids, but there was no
+single strategy for doing so. Many added features were provided as plugins,
+but then some were provided via subclassing. This made it very difficult (if
+not impossible) to combine certain features easily.
+
+Ext 4 includes a new grid base class called Ext.grid.Feature which provides
+the basis for creating extremely flexible optional grid features. The
+underlying templates can now be modified by any Feature classes in order to
+decorate or mutate the markup that the GridView generates. Features provide a
+powerful alternative to subclassing the old GridView because it makes it easy
+to mix and match compatible features.
+
+Some examples of the features now available in the Ext 4 grid are:
+
+ - RowWrap
+ - RowBody
+ - Grouping
+ - Chunking/Buffering
+
+#### Virtual Scrolling
+
+The Ext 4 grid now natively supports buffering its data during rendering,
+providing a virtual, load-on-demand view of its data. Grids will now easily
+support hundreds or even thousands of records without paging, which will be a
+massive improvement over Ext 3's grid capabilities.
+
+#### Editing Improvements
+
+In Ext 3 you had to use the specialized EditorGrid class to provide an
+editable grid, which limited its flexibility. In Ext 4 there is now an Editing
+plugin that can be applied to any grid instance, making it completely reusable
+across all grids.
+
+As part of the editing improvements, the popular RowEditor extension from Ext
+3 has been promoted to a first-class and fully-supported framework component
+in Ext 4.
+
+#### DataView
+
+The new GridView in Ext 4 extends the standard DataView class now. This not
+only minimizes duplicated code internally, it also makes the new grid even
+easier to customize. Because it extends DataView the new grid is also able to
+leverage the same selection models as any view, including discontinguous
+selection via keyboard navigation. The Home, End, PageDown and PageUp keys are
+also fully supported.
+
+### Panel
+
+#### Docking Support
+
+Panel now uses a panel-specific ComponentLayout class to manage a set of items
+docked to its borders. The Panel's `body` element is then sized to occupy any
+remaining space. Any components may be docked to any side of a panel via the
+new dockedItems config property, and docked items must be configured with a
+`dock` property to specify which border to dock to. This allows for amazingly
+flexible Panel layouts now -- things that were impossible in Ext 3 like
+vertically-docked side toolbars are now a breeze to implement in Ext 4.
+
+#### Header Improvements
+
+Header is now a first-class Container subclass, inheriting capabilities like
+child component management and layout. Headers may also be configured with a
+headerPosition of 'top', 'right', 'bottom' or 'left' via the new docking
+support.
+
+Tools (the small header buttons that perform actions like minimize, close,
+etc.) are also now proper Components making them even more flexible than they
+were in Ext 3.
+
+### Resizer
+
+Ext has had handle-based resizing built-in since the earliest days of the
+framework, but through Ext 3 it was limited to resizing DOM elements only. Now
+in Ext 4 any Component can be resized via the new Ext.resizer.Resizer and its
+associated components. This is mainly useful when applied to floating
+components, or components programmatically rendered outside of Ext's Container
+system.
+
+By configuring a component with resizable:true, resize handles are
+automatically added to the Component's edges. By default a proxy element is
+resized using the mouse, and the Component is resized on mouse up. Behavior of
+the resizer can be modified by specifying the `resizable` property as a config
+object for the Resizer class.
+
+### ComponentDragger
+
+Ext has always had extensive drag-and-drop support, but primarily at the DOM
+element level. In Ext 4, any Component can now easily be made draggable as
+well via the new Ext.util.ComponentDragger class. This is mainly useful for
+floating components, or components programmatically rendered outside of Ext's
+Container system.
+
+By configuring a component with draggable:true, it automatically becomes
+draggable with the mouse. Panels that are made draggable by this method
+(Windows configure themselves as draggable by default) show an empty ghost
+during the drag operation and the Panel or Window is shown in the new position
+on mouse up. Behavior of the dragger can be modified by specifying the
+draggable property as a config object for the ComponentDragger class.
+
+### Splitter
+
+Both the HBox and VBox layouts may contain Ext.resizer.Splitter components
+which are used to manage the size of their adjacent siblings. Minimum and
+maximum size settings are supported. By default, resizing a flexed item of a
+box layout sets its size in pixels and deletes the flex value. **One** of the
+splitter's two adjacent siblings may be configured with `maintainFlex:true` to
+preserve its flex value after the resize operation.
+
+### TabPanel
+
+As with many other components in Ext 4, the main pieces that make up a
+TabPanel have now been made into first-class Components in Ext 4. The Tab
+itself, just a DOM element in Ext 3, is now a Button subclass. The TabBar that
+contains the tabs is now a Container. These changes provide much more
+flexibility over Ext 3.
+
+Because tabs are now separate components from the contained child panels that
+hold the tab content, individual tab panels can now optionally show their own
+title header bars separately from their tab titles. This was impossible in Ext
+3.
+
+### Toolbar
+
+Toolbar is now a first-class Container, which will make adding new components
+and customizing its layout much easier than in Ext 3.
+
+## Theming
+
+The theming in Ext has always been amazing, but not as easy to customize as it
+could be. Ext 3 made strides in this area by separating structural and visual
+stylesheets, but there is still quite a bit of duplication, browser-specific
+override rules, and many other issues that are simply weaknesses of the CSS
+language itself.
+
+#### Resources
+
+ - [Ext 4 Theming (video)](http://vimeo.com/19159630)
+ - [Ext 4 Theming (slides)](http://www.slideshare.net/senchainc/slides-5971886)
+
+### Compass & SASS
+
+For Ext 4 we've completely retooled the theming system, switching to
+[Compass][27] and [SASS][28] as the primary CSS authoring tools internally.
+SASS is a superset of standard CSS that adds support for many advanced
+features:
+
+ - Nested selectors
+ - Variables
+ - Mixins
+ - Selector inheritance
+ - Compiled and easily compressed
+ - Ability to completely remove CSS for components not needed by your specific application
+
+### Markup Changes
+
+Ext now supports browser/version-specific markup for most components, which is
+a great advance from Ext 3.
+
+## Documentation
+
+ - Support for new class system constructs (requires, mixins, etc.)
+ - Support for @deprected members
+ - History navigation support
+ - Embedded examples, videos, etc.
+ - Favorite topics
+ - Multiple framework / version support
+ - Local search
+
+ [2]: http://www.sencha.com/forum/showthread.php?124015-Ext-3-to-4-Migration (Ext 3 to 4 Migration)
+ [5]: http://www.sencha.com/blog/countdown-to-ext-js-4-dynamic-loading-and-new-class-system
+ [7]: http://vimeo.com/17666102
+ [8]: http://vimeo.com/17733892
+ [10]: http://www.sencha.com/blog/countdown-to-ext-js-4-data-package/
+ [11]: http://www.sencha.com/blog/ext-js-4-anatomy-of-a-model/
+ [12]: http://edspencer.net/2011/02/proxies-extjs-4.html
+ [13]: http://www.sencha.com/blog/using-validations-and-associations-in-sencha-touch/
+ [14]: http://www.sencha.com/blog/ext-js-4-anatomy-of-a-model
+ [16]: http://vimeo.com/17673342
+ [17]: http://www.slideshare.net/senchainc/charts-5971878
+ [19]: http://vimeo.com/17917111
+ [20]: http://www.slideshare.net/senchainc/layouts-5971880
+ [25]: http://vimeo.com/19159630
+ [26]: http://www.slideshare.net/senchainc/slides-5971886
+ [27]: http://compass-style.org/ (Compass)
+ [28]: http://sass-lang.com/ (Sass: Syntactically Awesome Stylesheets)
+
git.ithinksw.org / extjs.git / blobdiff