X-Git-Url: http://git.ithinksw.org/extjs.git/blobdiff_plain/6746dc89c47ed01b165cc1152533605f97eb8e8d..f562e4c6e5fac7bcb445985b99acbea4d706e6f0:/docs/guides/upgrade/README.md diff --git a/docs/guides/upgrade/README.md b/docs/guides/upgrade/README.md new file mode 100644 index 00000000..752d3a1d --- /dev/null +++ b/docs/guides/upgrade/README.md @@ -0,0 +1,856 @@ +# 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 `
` +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) +