Ext.Net (Namespace)

*Assembly: *Ext.Net

Classes

Name|Description -|- AbsoluteLayoutConfig|This is a layout that inherits the anchoring of Ext.layout.container.Anchor and adds the ability for x/y positioning using the standard x and y component config options. This class is intended to be extended or created via the layout configuration property. See Ext.container.Container.layout for additional details. AbstractAssociation|Associations enable you to express relationships between different Models. Let's say we're writing an ecommerce system where Users can make Orders - there's a relationship between these Models that we can express like this: Ext.regModel('User', { fields: ['id', 'name', 'email'], hasMany: {model: 'Order', name: 'orders'} }); Ext.regModel('Order', { fields: ['id', 'userid', 'status', 'price'], belongsTo: 'User' }); We've set up two models - User and Order - and told them about each other. You can set up as many associations on each Model as you need using the two default types - hasMany and belongsTo. There's much more detail on the usage of each of those inside their documentation pages. AbstractAxis|Base class for all axis classes. AbstractCalendarView|This is an abstract class that serves as the base for other calendar views. This class is not intended to be directly instantiated. When extending this class to create a custom calendar view, you must provide an implementation for the renderItems method, as there is no default implementation for rendering events The rendering logic is totally dependent on how the UI structures its data, which is determined by the underlying UI template (this base class does not have a template). AbstractCalendarViewDirectEvents| AbstractCalendarViewListeners| AbstractComponent|Base class for all Ext components. All subclasses of AbstractComponent may participate in the automated Ext component lifecycle of creation, rendering and destruction which is provided by the Container class. Components may be added to a Container through the items config option at the time the Container is created, or they may be added dynamically via the add method. The AbstractComponent base class has built-in support for basic hide/show and enable/disable and size control behavior. All Components are registered with the Ext.ComponentMgr on construction so that they can be referenced at any time via Ext.getCmp, passing the id. All user-developed visual widgets that are required to participate in automated lifecycle and size management should subclass AbstractComponent. See the Creating new UI controls tutorial for details on how and to either extend or augment ExtJs base classes to create custom Components. Every component has a specific xtype, which is its Ext-specific type name, along with methods for checking the xtype like getXType and isXType. AbstractComponentCollectionBuilder<TParent, TParentBuilder>| AbstractComponentDirectEvents| AbstractComponentListeners| AbstractContainer| AbstractDataView|A mechanism for displaying data using custom layout templates and formatting. DataView uses an Ext.XTemplate as its internal templating mechanism, and is bound to an Ext.data.Store so that as the data in the store changes the view is automatically updated to reflect the changes. The view also provides built-in behavior for many common events that can occur for its contained items including click, doubleclick, mouseover, mouseout, etc. as well as a built-in selection model. In order to use these features, an itemSelector config must be provided for the DataView to determine what nodes it will be working with. AbstractDrawComponent|The Draw Component is a surface in which sprites can be rendered. The Draw Component manages and holds a Surface instance: an interface that has an SVG or VML implementation depending on the browser capabilities and where Sprites can be appended. AbstractPanel|A base class which provides methods common to Panel classes across the Sencha product range. Please refer to sub class's documentation AbstractProxy|Proxies are used by Stores to handle the loading and saving of Model data. Usually developers will not need to create or interact with proxies directly. Types of Proxy There are two main types of Proxy - Client and Server. The Client proxies save their data locally and include the following subclasses: LocalStorageProxy - saves its data to localStorage if the browser supports it SessionStorageProxy - saves its data to sessionStorage if the browsers supports it MemoryProxy - holds data in memory only, any data is lost when the page is refreshed The Server proxies save their data by sending requests to some remote server. These proxies include: AjaxProxy - sends requests to a server on the same domain JsonPProxy - uses JSON-P to send requests to a server on a different domain DirectProxt - uses Ext.direct to send requests Proxies operate on the principle that all operations performed are either Create, Read, Update or Delete. These four operations are mapped to the methods create, read, update and destroy respectively. Each Proxy subclass implements these functions. The CRUD methods each expect an Operation object as the sole argument. The Operation encapsulates information about the action the Store wishes to perform, the model instances that are to be modified, etc. See the Operation documentation for more details. Each CRUD method also accepts a callback function to be called asynchronously on completion. Proxies also support batching of Operations via a batch object, invoked by the batch method. AbstractReader|Readers are used to interpret data to be loaded into a Model instance or a Store - usually in response to an AJAX request. This is normally handled transparently by passing some configuration to either the Model or the Store in question - see their documentation for further details. Loading Nested Data Readers have the ability to automatically load deeply-nested data objects based on the associations configured on each Model. Below is an example demonstrating the flexibility of these associations in a fictional CRM system which manages a User, their Orders, OrderItems and Products. First we'll define the models: Ext.regModel("User", { fields: [ 'id', 'name' ], hasMany: {model: 'Order', name: 'orders'}, proxy: { type: 'rest', url : 'users.json', reader: { type: 'json', root: 'users' } } }); Ext.regModel("Order", { fields: [ 'id', 'total' ], hasMany : {model: 'OrderItem', name: 'orderItems', associationKey: 'orderitems'}, belongsTo: 'User' }); Ext.regModel("OrderItem", { fields: [ 'id', 'price', 'quantity', 'orderid', 'productid' ], belongsTo: ['Order', {model: 'Product', associationKey: 'product'}] }); Ext.regModel("Product", { fields: [ 'id', 'name' ], hasMany: 'OrderItem' }); This may be a lot to take in - basically a User has many Orders, each of which is composed of several OrderItems. Finally, each OrderItem has a single Product. This allows us to consume data like this: { "users": [ { "id": 123, "name": "Ed", "orders": [ { "id": 50, "total": 100, "orderitems": [ { "id" : 20, "price" : 40, "quantity": 2, "product" : { "id": 1000, "name": "MacBook Pro" } }, { "id" : 21, "price" : 20, "quantity": 3, "product" : { "id": 1001, "name": "iPhone" } } ] } ] } ] } The JSON response is deeply nested - it returns all Users (in this case just 1 for simplicity's sake), all of the Orders for each User (again just 1 in this case), all of the OrderItems for each Order (2 order items in this case), and finally the Product associated with each OrderItem. Now we can read the data and use it as follows: var store = new Ext.data.Store({ model: "User" }); store.load({ callback: function() { //the user that was loaded var user = store.first(); console.log("Orders for " + user.get('name') + ":") //iterate over the Orders for each User user.orders().each(function(order) { console.log("Order ID: " + order.getId() + ", which contains items:"); //iterate over the OrderItems for each Order order.orderItems().each(function(orderItem) { //we know that the Product data is already loaded, so we can use the synchronous getProduct //usually, we would use the asynchronous version (see Ext.data.BelongsToAssociation) var product = orderItem.getProduct(); console.log(orderItem.get('quantity') + ' orders of ' + product.get('name')); }); }); } }); Running the code above results in the following: Orders for Ed: Order ID: 50, which contains items: 2 orders of MacBook Pro 3 orders of iPhone AbstractSelectionModel| AbstractSelectionModelDirectEvents| AbstractSelectionModelListeners| AbstractSeries|Series is the abstract class containing the common logic to all chart series. Series includes methods from Labels, Highlights, Tips and Callouts mixins. This class implements the logic of handling mouse events, animating, hiding, showing all elements and returning the color of the series to be used as a legend item. The series class supports listeners via the Observable syntax. Some of these listeners are: itemmouseup When the user interacts with a marker. itemmousedown When the user interacts with a marker. itemmousemove When the user iteracts with a marker. afterrender Will be triggered when the animation ends or when the series has been rendered completely. AbstractStore|AbstractStore is a superclass of Ext.data.Store and Ext.data.TreeStore. It's never used directly, but offers a set of methods used by both of those subclasses. We've left it here in the docs for reference purposes, but unless you need to make a whole new type of Store, what you're probably looking for is Ext.data.Store. If you're still interested, here's a brief description of what AbstractStore is and is not. AbstractStore provides the basic configuration for anything that can be considered a Store. It expects to be given a Model that represents the type of data in the Store. It also expects to be given a Proxy that handles the loading of data into the Store. AbstractStore provides a few helpful methods such as load and sync, which load and save data respectively, passing the requests through the configured proxy. Both built-in Store subclasses add extra behavior to each of these functions. Note also that each AbstractStore subclass has its own way of storing data - in Ext.data.Store the data is saved as a flat MixedCollection, whereas in TreeStore we use a Ext.data.Tree to maintain the data's hierarchy. The store provides filtering and sorting support. This sorting/filtering can happen on the client side or can be completed on the server. This is controlled by the remoteSort and remoteFilter config options. For more information see the sort and filter methods. AbstractStoreDirectEvents| AbstractStoreListeners| AbstractSummary|A small abstract class that contains the shared behaviour for any summary calculations to be used in the grid. AbstractTabPanel| AbstractValidation|Abstract validation type AbstractWindow| AbstractWriter|Base Writer class used by most subclasses of Ext.data.proxy.Server. This class is responsible for taking a set of Ext.data.Operation objects and a Ext.data.Request object and modifying that request based on the Operations. For example a Ext.data.writer.Json would format the Operations and their Ext.data.Model instances based on the config options passed to the JsonWriter's constructor. Writers are not needed for any kind of local storage - whether via a Web Storage proxy (see localStorage and sessionStorage) or just in memory via a MemoryProxy. AccordionLayoutConfig|This is a layout that manages multiple Panels in an expandable accordion style such that only one Panel can be expanded at any given time. Each Panel has built-in support for expanding and collapsing. Note: Only Ext.Panels and all subclasses of Ext.panel.Panel may be used in an accordion layout Container. ActionColumn|A Grid header type which renders an icon, or a series of icons in a grid cell, and offers a scoped click handler for each icon. The action column can be at any index in the columns array, and a grid can have any number of action columns. ActionItem|Action column item definition ActionItemCollection| AfterDirectEventArgs| AfterRecordDeletedEventArgs| AfterRecordInsertedEventArgs| AfterRecordUpdatedEventArgs| AfterStoreChangedEventArgs| AjaxOptions|Options to be passed to the request AjaxProxy| AjaxRequestFilter| AnchorLayoutConfig|This is a layout that enables anchoring of contained elements relative to the container's dimensions. If the container is resized, all anchored items are automatically rerendered according to their anchor rules. This class is intended to be extended or created via the layout: 'anchor' Ext.layout.AbstractContainer-layout config, and should generally not need to be created directly via the new keyword. AnchorLayout does not have any direct config options (other than inherited ones). By default, AnchorLayout will calculate anchor measurements based on the size of the container itself. However, the container using the AnchorLayout can supply an anchoring-specific config property of anchorSize. If anchorSize is specifed, the layout will use it as a virtual container for the purposes of calculating anchor measurements based on it instead, allowing the container to be sized independently of the anchoring logic if necessary. AnimConfig|Perform custom animation on this object. This method is applicable to both the Component class and the Element class. It performs animated transitions of certain properties of this object over a specified timeline. The sole parameter is an object which specifies start property values, end property values, and properties which describe the timeline. Animating an Element When animating an Element, the following properties may be specified in from, to, and keyframe objects: x - The page X position in pixels. y - The page Y position in pixels left - The element's CSS left value. Units must be supplied. top - The element's CSS top value. Units must be supplied. width - The element's CSS width value. Units must be supplied. height - The element's CSS height value. Units must be supplied. scrollLeft - The element's scrollLeft value. scrollTop - The element's scrollLeft value. opacity - The element's opacity value. This must be a value between 0 and 1. Be aware than animating an Element which is being used by an Ext Component without in some way informing the Component about the changed element state will result in incorrect Component behaviour. This is because the Component will be using the old state of the element. To avoid this problem, it is now possible to directly animate certain properties of Components. Animating a Component When animating a Component, the following properties may be specified in from, to, and keyframe objects: x - The Component's page X position in pixels. y - The Component's page Y position in pixels left - The Component's left value in pixels. top - The Component's top value in pixels. width - The Component's width value in pixels. width - The Component's width value in pixels. dynamic - Specify as true to update the Component's layout (if it is a Container) at every frame of the animation. Use sparingly as laying out on every intermediate size change is an expensive operation. AnimConfigListeners| App|Represents an Ext JS 4 application, which is typically a single page app using a Viewport. A typical Ext.app.Application might look like this: Ext.application({ name: 'MyApp', launch: function() { Ext.create('Ext.container.Viewport', { items: { html: 'My App' } }); } }); This does several things. First it creates a global variable called 'MyApp' - all of your Application's classes (such as its Models, Views and Controllers) will reside under this single namespace, which drastically lowers the chances of colliding global variables. The MyApp global will also have a getApplication method to get a reference to the current application: var app = MyApp.getApplication(); When the page is ready and all of your JavaScript has loaded, your Application's launch function is called, at which time you can run the code that starts your app. Usually this consists of creating a Viewport, as we do in the example above. Telling Application about the rest of the app Because an Ext.app.Application represents an entire app, we should tell it about the other parts of the app - namely the Models, Views and Controllers that are bundled with the application. Let's say we have a blog management app; we might have Models and Controllers for Posts and Comments, and Views for listing, adding and editing Posts and Comments. Here's how we'd tell our Application about all these things: Ext.application({ name: 'Blog', models: ['Post', 'Comment'], controllers: ['Posts', 'Comments'], launch: function() { ... } }); Note that we didn't actually list the Views directly in the Application itself. This is because Views are managed by Controllers, so it makes sense to keep those dependencies there. The Application will load each of the specified Controllers using the pathing conventions laid out in the application architecture guide - in this case expecting the controllers to reside in app/controller/Posts.js and app/controller/Comments.js. In turn, each Controller simply needs to list the Views it uses and they will be automatically loaded. Here's how our Posts controller like be defined: Ext.define('MyApp.controller.Posts', { extend: 'Ext.app.Controller', views: ['posts.List', 'posts.Edit'], //the rest of the Controller here }); Because we told our Application about our Models and Controllers, and our Controllers about their Views, Ext JS will automatically load all of our app files for us. This means we don't have to manually add script tags into our html files whenever we add a new class, but more importantly it enables us to create a minimized build of our entire application using Sencha Cmd. Deriving from Ext.app.Application Typically, applications do not derive directly from Ext.app.Application. Rather, the configuration passed to Ext.application mimics what you might do in a derived class. In some cases, however, it can be desirable to share logic by using a derived class from Ext.app.Application. Derivation works as you would expect, but using the derived class should still be the job of the Ext.application method. Ext.define('MyApp.app.Application', { extend: 'Ext.app.Application', ... }); Ext.application('MyApp.app.Application'); For more information about writing Ext JS 4 applications, please see the application architecture guide. AppInit| AppRef|Config to build up a reference to a view on a page AreaSeries|Creates a Stacked Area Chart. The stacked area chart is useful when displaying multiple aggregated layers of information. As with all other series, the Area Series must be appended in the series Chart array configuration. ArrayReader| AssociationCollection| AsyncTreeNodeListeners| AutoLoadParamsJsonConverter| Axis|Defines axis for charts. The axis position, type, style can be configured. The axes are defined in an axes array of configuration objects where the type, field, grid and other configuration options can be set. AxisCollection| AxisGrid|The grid configuration enables you to set a background grid for an axis. If set to true on a vertical axis, vertical lines will be drawn. If set to true on a horizontal axis, horizontal lines will be drawn. If both are set, a proper grid with horizontal and vertical lines will be drawn. You can set specific options for the grid configuration for odd and/or even lines/rows. Since the rows being drawn are rectangle sprites, you can set to an odd or even property all styles that apply to Ext.draw.Sprite. For more information on all the style properties you can set please take a look at Ext.draw.Sprite. Some useful style properties are opacity, fill, stroke, stroke-width, etc. The possible values for a grid option are then true, false, or an object with { odd, even } properties where each property contains a sprite style descriptor object that is defined in Ext.draw.Sprite. AxisLabel| BarSeries|Creates a Bar Chart. A Bar Chart is a useful visualization technique to display quantitative information for different categories that can show some progression (or regression) in the dataset. As with all other series, the Bar Series must be appended in the series Chart array configuration. BaseControl| BaseDirectEvent| BaseFilter| BaseItem| BaseItemCollection<T>| BaseListener| BaseLoadConfig| BaseParameter| BaseScriptBuilder| BaseTriggerField| BBarCollectionBuilder<TParent, TParentBuilder>| BeforeDirectEventArgs| BeforeRecordDeletedEventArgs| BeforeRecordInsertedEventArgs| BeforeRecordUpdatedEventArgs| BeforeStoreChangedEventArgs| BelongsToAssociation|Represents a many to one association with another model. The owner model is expected to have a foreign key which references the primary key of the associated model: var Category = Ext.regModel('Category', { fields: [ {name: 'id', type: 'int'}, {name: 'name', type: 'string'} ] }); var Product = Ext.regModel('Product', { fields: [ {name: 'id', type: 'int'}, {name: 'categoryid', type: 'int'}, {name: 'name', type: 'string'} ], associations: [ {type: 'belongsTo', model: 'Category'} ] }); In the example above we have created models for Products and Categories, and linked them together by saying that each Product belongs to a Category. This automatically links each Product to a Category based on the Product's categoryid, and provides new functions on the Product model: Generated getter function The first function that is added to the owner model is a getter function: var product = new Product({ id: 100, categoryid: 20, name: 'Sneakers' }); product.getCategory(function(category, operation) { //do something with the category object alert(category.get('id')); //alerts 20 }, this); The getCategory function was created on the Product model when we defined the association. This uses the Category's configured proxy to load the Category asynchronously, calling the provided callback when it has loaded. The new getCategory function will also accept an object containing success, failure and callback properties - callback will always be called, success will only be called if the associated model was loaded successfully and failure will only be called if the associatied model could not be loaded: product.getCategory({ callback: function(category, operation) {}, //a function that will always be called success : function(category, operation) {}, //a function that will only be called if the load succeeded failure : function(category, operation) {}, //a function that will only be called if the load did not succeed scope : this //optionally pass in a scope object to execute the callbacks in }); In each case above the callbacks are called with two arguments - the associated model instance and the operation object that was executed to load that instance. The Operation object is useful when the instance could not be loaded. Generated setter function The second generated function sets the associated model instance - if only a single argument is passed to the setter then the following two calls are identical: //this call product.setCategory(10); //is equivalent to this call: product.set('categoryid', 10); If we pass in a second argument, the model will be automatically saved and the second argument passed to the owner model's save method: product.setCategory(10, function(product, operation) { //the product has been saved alert(product.get('categoryid')); //now alerts 10 }); //alternative syntax: product.setCategory(10, { callback: function(product, operation), //a function that will always be called success : function(product, operation), //a function that will only be called if the load succeeded failure : function(product, operation), //a function that will only be called if the load did not succeed scope : this //optionally pass in a scope object to execute the callbacks in }) Customisation Associations reflect on the models they are linking to automatically set up properties such as the primaryKey and foreignKey. These can alternatively be specified: var Product = Ext.regModel('Product', { fields: [...], associations: [ {type: 'belongsTo', model: 'Category', primaryKey: 'uniqueid', foreignKey: 'catid'} ] }); Here we replaced the default primary key (defaults to 'id') and foreign key (calculated as 'categoryid') with our own settings. Usually this will not be needed. BooleanColumn| BooleanFilter| BorderLayoutConfig|This is a multi-pane, application-oriented UI layout style that supports multiple nested panels, automatic bars between regions and built-in expanding and collapsing of regions. This class is intended to be extended or created via the layout:'border' Ext.container.Container.layout config, and should generally not need to be created directly via the new keyword. Notes When using the split option, the layout will automatically insert a Ext.resizer.Splitter into the appropriate place. This will modify the underlying items collection in the container. Any Container using the Border layout must have a child item with region:'center'. The child item in the center region will always be resized to fill the remaining space not used by the other regions in the layout. Any child items with a region of west or east may be configured with either an initial width, or a Ext.layout.container.Box.flex value, or an initial percentage width string (Which is simply divided by 100 and used as a flex value). The 'center' region has a flex value of 1. Any child items with a region of north or south may be configured with either an initial height, or a Ext.layout.container.Box.flex value, or an initial percentage height string (Which is simply divided by 100 and used as a flex value). The 'center' region has a flex value of 1. There is no BorderLayout.Region class in ExtJS 4.0+ BoundList|An internally used DataView for ComboBox. BoundListBase| Box| BoxLayoutConfig|Base Class for HBoxLayout and VBoxLayout Classes. BoxReorderer|Plugin which can be attached to any container instance with VBox/HBox layout. Provides ability to reorder container items with drag and drop. BoxReordererDirectEvents| BoxReordererListeners| BoxSplitter|This class functions between siblings of a VBox or HBox layout to resize both immediate siblings. A Splitter will preserve the flex ratio of any flexed siblings it is required to resize. It does this by setting the flex property of all flexed siblings to equal their pixel size. The actual numerical flex property in the Components will change, but the ratio to the total flex value will be preserved. A Splitter may be configured to show a centered mini-collapse tool orientated to collapse the collapseTarget. The Splitter will then call that sibling Panel's collapse or expand method to perform the appropriate operation (depending on the sibling collapse state). To create the mini-collapse tool but take care of collapsing yourself, configure the splitter with performCollapse: false. BufferedRenderer|Implements buffered rendering of a grid, allowing users can scroll through thousands of records without the performance penalties of renderering all the records on screen at once. The grid should be bound to a store with a pageSize specified. The number of rows rendered outside the visible area, and the buffering of pages of data from the remote server for immediate rendering upon scroll can be controlled by configuring the plugin. You can tell it to create a larger table to provide more scrolling before a refresh is needed, and also to keep more pages of records in memory for faster refreshing when scrolling. BuilderFactory| Button| ButtonBase| ButtonCollection| ButtonCollectionEditor| ButtonConverter| ButtonDirectEvents| ButtonGroup| ButtonListeners| ButtonsCollectionBuilder<TParent, TParentBuilder>| CalendarCombo|A custom combo used for choosing from the list of available calendars to assign an event to. You must pass a populated calendar store as the store config or the combo will not work. This is pretty much a standard combo that is simply pre-configured for the options needed by the calendar components. CalendarMappingsContractResolver| CalendarModel|This is the Record specification for calendar items used by the CalendarPanel's calendar store. If your model fields are named differently you should update the mapping configs accordingly. The only required fields when creating a new calendar record instance are CalendarId and Title. All other fields are either optional or will be defaulted if blank. CalendarModelCollection| CalendarPanel|This is the default container for calendar views. It supports day, week, multi-week and month views as well as a built-in event edit form. The only requirement for displaying a calendar is passing in a valid store config containing records of type EventRecord. CalendarPanelBase| CalendarPanelDirectEvents| CalendarPanelListeners| CalendarStore|A simple reusable store that loads static calendar field definitions into memory and can be bound to the CalendarCombo widget and used for calendar color selection. CapsLockDetector| CapsLockDetectorDirectEvents| CapsLockDetectorListeners| CardLayoutConfig|This layout manages multiple child Components, each fitted to the Container, where only a single child Component can be visible at any given time. This layout style is most commonly used for wizards, tab implementations, etc. This class is intended to be extended or created via the layout:'card' Ext.container.Container-layout config, and should generally not need to be created directly via the new keyword. The CardLayout's focal method is setActiveItem. Since only one panel is displayed at a time, the only way to move from one Component to the next is by calling setActiveItem, passing the id or index of the next panel to display. The layout itself does not provide a user interface for handling this navigation, so that functionality must be provided by the developer. CartesianSeries|Common base class for series implementations which plot values using x/y coordinates. CategoryAxis|A type of axis that displays items in categories. This axis is generally used to display categorical information like names of items, month names, quarters, etc. but no quantitative values. For that other type of information Number axis are more suitable. CellCommandColumn| CellCommandColumnDirectEvents| CellCommandColumnListeners| CellDragDrop| CellEditing|The Ext.grid.plugin.CellEditing plugin injects editing at a cell level for a Grid. Only a single cell will be editable at a time. The field that will be used for the editor is defined at the field. The editor can be a field instance or a field configuration. If an editor is not specified for a particular column then that cell will not be editable and it will be skipped when activated via the mouse or the keyboard. The editor may be shared for each column in the grid, or a different one may be specified for each column. An appropriate field type should be chosen to match the data structure that it will be editing. For example, to edit a date, it would be useful to specify Ext.form.field.Date as the editor. CellEditingDirectEvents| CellEditingListeners| CellEditorOptions| CellSelectionModel|Implement cell based navigation via keyboard. CellSelectionModelDirectEvents| CellSelectionModelListeners| ChainingPropertyInfo| ChangeRecords<T>| Chart|Charts provide a flexible way to achieve a wide range of data visualization capablitities. Each Chart gets its data directly from a Store, and automatically updates its display whenever data in the Store changes. In addition, the look and feel of a Chart can be customized using Themes. Every Chart has three key parts - a Store that contains the data, an array of Axes which define the boundaries of the Chart, and one or more Series to handle the visual rendering of the data points. Axes are the lines that define the boundaries of the data points that a Chart can display. Series are responsible for the visual representation of the data points contained in the Store. ChartDirectEvents| ChartLegend|Defines a legend for a chart's series. The 'chart' member must be set prior to rendering. The legend class displays a list of legend items each of them related with a series being rendered. In order to render the legend item of the proper series the series configuration object must have showInSeries set to true. The legend configuration object accepts a position as parameter. The position parameter can be left, right top or bottom. ChartListeners| ChartTheme|Provides chart theming. ChartTip|Provides tips for Ext.chart.series.Series. Checkbox| CheckboxBase| CheckboxConverter| CheckboxDirectEvents| CheckboxGroup| CheckboxGroupBase| CheckboxGroupDirectEvents| CheckboxGroupLayoutConfig|This is a base class for layouts that contain a single item that automatically expands to fill the layout's container. This class is intended to be extended or created via the layout:'fit' Ext.container.Container.layout config, and should generally not need to be created directly via the new keyword. Fit layout does not have any direct config options (other than inherited ones). To fit a panel to a container using Fit layout, simply set layout: 'fit' on the container and add a single panel to it. If the container has multiple items, all of the items will all be equally sized. This is usually not desired, so to avoid this, place only a single item in the container. This sizing of all items can be used to provide a background image that is "behind" another item such as a dataview if you also absolutely position the items. CheckboxGroupListeners| CheckboxListeners| CheckboxSelectionModel|A selection model that renders a column of checkboxes that can be toggled to select or deselect rows. The default mode for this selection model is MULTI. The selection model will inject a header for the checkboxes in the first view and according to the 'injectCheckbox' configuration. CheckColumn| CheckColumnDirectEvents| CheckColumnListeners| CheckMenuItem| CheckMenuItemDirectEvents| CheckMenuItemListeners| ChildElement|The child element of the Component. It is used as an item of the AbstractComponenn's ChildEls. ChildElementCollection| Chunking| ClearButton| ClearButtonDirectEvents| ClearButtonListeners| ClickRepeater| ClickRepeaterDirectEvents| ClickRepeaterListeners| ClientConfig| ClientResourceItem| ClientScriptItem| ClientStyleItem| ColorMenu| ColorMenuDirectEvents| ColorMenuListeners| ColorPicker| ColorPickerDirectEvents| ColorPickerListeners| Column| ColumnBase| ColumnCollection| ColumnDirectEvents| ColumnLayoutConfig|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 fixed width, but the height is allowed to vary based on the content. This class is intended to be extended or created via the layout:'column' Ext.container.Container.layout config, and should generally not need to be created directly via the new keyword. ColumnLayout does not have any direct config options (other than inherited ones), but it does support a specific config property of columnWidth that can be included in the config of any panel added to it. The layout will use the columnWidth (if present) or width of each panel during layout to determine how to size each panel. If width or columnWidth is not specified for a given panel, its width will default to the panel's width (or auto). The width property is always evaluated as pixels, and must be a number greater than or equal to 1. The columnWidth property is always evaluated as a percentage, and must be a decimal value greater than 0 and less than 1 (e.g., .25). The basic rules for specifying column widths are pretty simple. The logic makes two passes through the set of contained panels. During the first layout pass, all panels that either have a fixed width or none specified (auto) are skipped, but their widths are subtracted from the overall container width. During the second pass, all panels with columnWidths are assigned pixel widths in proportion to their percentages based on the total remaining container width. In other words, percentage width panels are designed to fill the space left over by all the fixed-width and/or auto-width panels. Because of this, while you can specify any number of columns with different percentages, the columnWidths must always add up to 1 (or 100%) when added together, otherwise your layout may not render as expected. ColumnListeners| ColumnSeries|Creates a Column Chart. Much of the methods are inherited from Bar. A Column Chart is a useful visualization technique to display quantitative information for different categories that can show some progression (or regression) in the data set. As with all other series, the Column Series must be appended in the series Chart array configuration. ComboBox| ComboBoxBase| ComboBoxDirectEvents| ComboBoxListeners| CommandColumn| CommandFill| CommandMenu| CommandSeparator| CommandSpacer| CommandText| Component| ComponentAddedEventArgs| ComponentBase|Base class for all Ext components. All subclasses of Component may participate in the automated Ext component lifecycle of creation, rendering and destruction which is provided by the Container class. Components may be added to a Container through the items config option at the time the Container is created, or they may be added dynamically via the add method. The Component base class has built-in support for basic hide/show and enable/disable and size control behavior. All Components are registered with the Ext.ComponentManager on construction so that they can be referenced at any time via Ext.getCmp, passing the id. All user-developed visual widgets that are required to participate in automated lifecycle and size management should subclass Component. See the Creating new UI controls chapter in [Component Guide][1] for details on how and to either extend or augment Ext JS base classes to create custom Components. Every component has a specific xtype, which is its Ext-specific type name, along with methods for checking the xtype like getXType and isXType. See the [Component Guide][1] for more information on xtypes and the Component hierarchy. ComponentColumn| ComponentColumnDirectEvents| ComponentColumnListeners| ComponentDirectEvent| ComponentDirectEvents| ComponentDragger|A subclass of Ext.dd.DragTracker which handles dragging any AbstractComponent. This is configured with a AbstractComponent to be made draggable, and a config object for the Ext.dd.DragTracker class. A delegate may be provided which may be either the element to use as the mousedown target or a Ext.DomQuery selector to activate multiple mousedown targets. ComponentListener| ComponentListeners| ComponentLoader|A class used to load remote content to a component. In general this class will not be instanced directly, rather a loader configuration will be passed to the constructor of the Ext.AbstractComponent ComponentLoaderDirectEvents| ComponentLoaderListeners| ComponentManager| ComponentView| ComponentViewDirectEvents| ComponentViewListeners| ConfigBagJsonConverter| ConfigItem| ConfigItemCollection| ConfigOption| ConfigOptionAttribute| ConfigOptionsCollection| ConfigScriptBuilder| Const| Container| ContainerDirectEvents| ContainerListeners| ContentContainer| ContentScriptBuilder| ControlBuilder| ControlBuilder<TComponent, TBuilder>| ControlConverter| ControlState| Cookies| CRUDDirect| CRUDMethods|Mapping of action name to HTTP request method. CRUDUrls|Specific urls to call on CRUD action methods "read", "create", "update" and "destroy" CSS| CtorDateTimeJsonConverter| CustomAttributeBinding| CustomConfigJsonConverter| CustomIdGenerator| CycleButton| CycleButtonDirectEvents| CycleButtonListeners| DataFilter|Represents a filter that can be applied to a MixedCollection. Can either simply filter on a property/value pair or pass in a filter function with custom logic. Filters are always used in the context of MixedCollections, though Stores frequently create them when filtering and searching on their records. DataFilterCollection| DataProxyDirectEvents| DataSorter| DataSorterCollection| DataTip| DataView| DataViewAnimated| DataViewDirectEvents| DataViewDraggable| DataViewDragSelector| DataViewLabelEditor| DataViewListeners| DateColumn| DateField|Provides a date input field with a date picker dropdown and automatic date validation. This field recognizes and uses the JavaScript Date object as its main value type. In addition, it recognizes string values which are parsed according to the format and/or altFormats configs. These may be reconfigured to use date formats appropriate for the user's locale. The field may be limited to a certain range of dates by using the minValue, maxValue, disabledDays, and disabledDates config parameters. These configurations will be used both in the field's validation, and in the date picker dropdown by preventing invalid dates from being selected. DateFieldBase| DateFieldDirectEvents| DateFieldListeners| DateFilter| DateMenu| DateMenuDirectEvents| DateMenuListeners| DatePicker| DatePickerDirectEvents| DatePickerListeners| DatePickerOptions| DateRangeField|A combination field that includes start and end dates and times, as well as an optional all-day checkbox. DayView|Unlike other calendar views, is not actually a subclass of CalendarView. Instead it is a Container subclass that internally creates and manages the layouts of a DayHeaderView and a DayBodyView. As such DayView accepts any config values that are valid for DayHeaderView and DayBodyView and passes those through to the contained views. It also supports the interface required of any calendar view and in turn calls methods on the contained views as necessary. DD| DDProxy| DDTarget| DefaultResourcesStrategy| DefaultScriptBuilder| DefaultSelectionModelDirectEvents| DefaultSelectionModelListeners| DefaultTabMenuCollectionBuilder<TParent, TParentBuilder>| DeferredRenderAttribute| DesignerActionHeaderItemComparer| Desktop| DesktopConfig| DesktopDirectEvents| DesktopListeners| DesktopModule| DesktopModuleProxy| DesktopModulesCollection| DesktopShortcut| DesktopShortcuts| DesktopStartMenu| DesktopTaskBar| DirectEvent| DirectEventArgs| DirectEventCollection| DirectEventConfirmation| DirectEventHandlerJsonConverter| DirectEventJsonConverter| DirectEventsConverter| DirectEventTriplet| DirectEventUpdateAttribute| DirectMethodAttribute| DirectMethodHandler| DirectMethodProxyIDAttribute| DirectProxy|This class is used to send requests to the server using Ext.direct. When a request is made, the transport mechanism is handed off to the appropriate Provider to complete the call. Specifying the function This proxy expects a Direct remoting method to be passed in order to be able to complete requests. This can be done by specifying the directFn configuration. This will use the same direct method for all requests. Alternatively, you can provide an api configuration. This allows you to specify a different remoting method for each CRUD action. Paramaters This proxy provides options to help configure which parameters will be sent to the server. By specifying the paramsAsHash option, it will send an object literal containing each of the passed parameters. The paramOrder option can be used to specify the order in which the remoting method parameters are passed. Example Usage Ext.define('User', { extend: 'Ext.data.Model', fields: ['firstName', 'lastName'], proxy: { type: 'direct', directFn: MyApp.getUsers, paramOrder: 'id' // Tells the proxy to pass the id as the first parameter to the remoting method. } }); User.load(1); DirectRequestModule| DirectResponse| DisabledDate|These strings will be used to build a dynamic regular expression so they are very powerful. Some examples: ['03/08/2003', '09/16/2003'] would disable those exact dates ['03/08', '09/16'] would disable those days for every year ['03/08'] would only match the beginning (useful if you are using short years) ['03/../2006'] would disable every day in March 2006 ['03'] would disable every day in every March Note that the format of the dates included in the array should exactly match the format config. In order to support regular expressions, if you are using a date format that has '.' in it, you will have to escape the dot when restricting dates. For example: ['03.08.03']. DisabledDateCollection| DisplayField| DisplayTimeField| Dom| DomHelper| DomObject| DomObjectCollection| DragDrop| DragDropGroup| DragDropGroups| DragSource| DragTracker|A DragTracker listens for drag events on an Element and fires events at the start and end of the drag, as well as during the drag. This is useful for components such as Ext.slider.Multi, where there is an element that can be dragged around to change the Slider's value. DragTracker provides a series of template methods that should be overridden to provide functionality in response to detected drag operations. These are onBeforeStart, onStart, onDrag and onEnd. See Ext.slider.Multi's initEvents function for an example implementation. DragTrackerDirectEvents| DragTrackerListeners| DragZone| DrawBackground| DrawComponent|The Draw Component is a surface in which sprites can be rendered. The Draw Component manages and holds a Surface instance: an interface that has an SVG or VML implementation depending on the browser capabilities and where Sprites can be appended. DrawComponentDirectEvents| DrawComponentListeners| DrawText|This class encapsulates a drawn text item as rendered by the Ext.draw package within a Component which can be then used anywhere in an ExtJS application just like any other Component. DropDownField| DropDownFieldBase| DropTarget| DropZone| DynamicConfigDictionary| Editor| EditorAlignmentConfig| EditorAutoSize| EditorCollection| EditorDirectEvents| EditorListeners| Element| ElementFxConfig| ElementListeners| EmailValidation|Validates that the given value is present EmptyDesigner| EnumJsonConverter| EnumToIntConverter| EventDetails|A custom form used for detailed editing of events. This is pretty much a standard form that is simply pre-configured for the options needed by the calendar components. It is also configured to automatically bind records of type Extensible.calendar.data.EventModel to and from the form. This form also provides custom events specific to the calendar so that other calendar components can be easily notified when an event has been edited via this component. EventDetailsBase| EventDetailsDirectEvents| EventDetailsListeners| EventMappingsContractResolver| EventMask| EventModel|This is the specification for calendar event data used by the CalendarPanel's underlying store. It can be overridden as necessary to customize the fields supported by events, although the existing column names should not be altered. If your model fields are named differently you should update the mapping configs accordingly. The only required fields when creating a new event record instance are StartDate and EndDate. All other fields are either optional are will be defaulted if blank. EventModelCollection| EventStore| EventWindow|A custom window containing a basic edit form used for quick editing of events. This window also provides custom events specific to the calendar so that other calendar components can be easily notified when an event has been edited via this component. EventWindowBase| EventWindowDirectEvents| EventWindowListeners| ExcessItemsException| ExclusionValidation|Validates that the given value is present in the configured list ExtControlActionList| ExtControlDesigner| Extensions| ExtJsonConverter| ExtNet| ExtNetTransformer| ExtObject| FadeIn| FadeInConfig| FadeOut| FadeOutConfig| FBarCollectionBuilder<TParent, TParentBuilder>| Field| FieldContainer|FieldContainer is a derivation of Container that implements the Labelable mixin. This allows it to be configured so that it is rendered with a field label and optional error message around its sub-items. This is useful for arranging a group of fields or other components within a single item in a form, so that it lines up nicely with other fields. A common use is for grouping a set of related fields under a single label in a form. The container's configured items will be layed out within the field body area according to the configured layout type. The default layout is 'autocontainer'. Like regular fields, FieldContainer can inherit its decoration configuration from the fieldDefaults of an enclosing FormPanel. In addition, FieldContainer itself can pass fieldDefaults to any fields it may itself contain. If you are grouping a set of Checkbox or Radio fields in a single labeled container, consider using a Ext.form.CheckboxGroup or Ext.form.RadioGroup instead as they are specialized for handling those types. FieldContainerBase| FieldContainerDirectEvents| FieldContainerListeners| FieldDirectEvents| FieldListeners| FieldReplicator| FieldSet| FieldSetDirectEvents| FieldSetListeners| FieldTrigerCollection| FieldTrigger| FileUploadEventArgs| FileUploadField| FileUploadFieldDirectEvents| FileUploadFieldListeners| FilterCondition| FilterConditionCollection| FilterConditions| FilterHeader| FilterHeaderComparator<T>| FilterHeaderCondition| FilterHeaderConditions| FilterHeaderDirectEvents| FilterHeaderListeners| FilterHeaderValue| FitLayoutConfig|This is a base class for layouts that contain a single item that automatically expands to fill the layout's container. This class is intended to be extended or created via the layout:'fit' Ext.container.Container.layout config, and should generally not need to be created directly via the new keyword. Fit layout does not have any direct config options (other than inherited ones). To fit a panel to a container using Fit layout, simply set layout: 'fit' on the container and add a single panel to it. If the container has multiple items, all of the items will all be equally sized. This is usually not desired, so to avoid this, place only a single item in the container. This sizing of all items can be used to provide a background image that is "behind" another item such as a dataview if you also absolutely position the items. FlashButtonConfig| FlashComponent| FlashComponentDirectEvents| FlashComponentListeners| FormatValidation|Returns true if the given value passes validation against the configured matcher regex FormLayoutConfig|This is a layout that will render form Fields, one under the other all stretched to the Container width. FormPanel| FormPanelBase| FormPanelDirectEvents| FormPanelListeners| Frame| FunctionItemCollectionJsonConverter| FunctionItemsCollectionJsonConverter| FunctionJsonConverter| FunctionLazyControlJsonConverter| Fx| FxConfig| GaugeAxis|Gauge Axis is the axis to be used with a Gauge series. The Gauge axis displays numeric data from an interval defined by the minimum, maximum and step configuration properties. The placement of the numeric data can be changed by altering the margin option that is set to 10 by default. GaugeSeries|Creates a Gauge Chart. Gauge Charts are used to show progress in a certain variable. There are two ways of using the Gauge chart. One is setting a store element into the Gauge and selecting the field to be used from that store. Another one is instantiating the visualization and using the setValue method to adjust the value you want. GenericComponent<T>| GenericConverter| GenericFeature|A generic Plugin. GenericPlugin| Ghost| GlobalConfig| Gradient| Gradients| GradientStop| GradientStops| GridCommand| GridCommandBase| GridCommandCollection| GridDragDrop|This plugin provides drag and/or drop functionality for a GridView. It creates a specialized instance of DragZone which knows how to drag out of a GridView and loads the data object which is passed to a cooperating DragZone's methods with the following properties: copy : Boolean The value of the GridView's copy property, or true if the GridView was configured with allowCopy: true and the control key was pressed when the drag operation was begun. view : GridView The source GridView from which the drag originated. ddel : HtmlElement The drag proxy element which moves with the mouse item : HtmlElement The GridView node upon which the mousedown event was registered. records : Array An Array of Models representing the selected data being dragged from the source GridView. It also creates a specialized instance of Ext.dd.DropZone which cooperates with other DropZones which are members of the same ddGroup which processes such data objects. Adding this plugin to a view means that two new events may be fired from the client GridView, beforedrop and drop GridEditing|This class provides an abstract grid editing plugin on selected columns. The editable columns are specified by providing an editor in the column configuration. GridFeature|A feature is a type of plugin that is specific to the Ext.grid.Panel. It provides several hooks that allows the developer to inject additional functionality at certain points throughout the grid creation cycle. This class provides the base template methods that are available to the developer, it should be extended. There are several built in features that extend this class, for example: Ext.grid.feature.Grouping - Shows grid rows in groups as specified by the Ext.data.Store Ext.grid.feature.RowBody - Adds a body section for each grid row that can contain markup. Ext.grid.feature.Summary - Adds a summary row at the bottom of the grid with aggregate totals for a column. GridFilter| GridFilterCollection| GridFilterListeners| GridFilters| GridFiltersDirectEvents| GridFiltersListeners| GridHeaderContainer|Container which holds headers and is docked at the top or bottom of a TablePanel. The HeaderContainer drives resizing/moving/hiding of columns within the TableView. As headers are hidden, moved or resized the headercontainer is responsible for triggering changes within the view. GridHeaderContainerDirectEvents| GridHeaderContainerListeners| GridPanel| GridPanelBase| GridPanelDirectEvents| GridPanelListeners| GridView| GridViewDirectEvents| GridViewListeners| GroupImageCommand| GroupImageCommandCollection| Grouping|This feature allows to display the grid rows aggregated into groups as specified by the Ext.data.Store.groupers specified on the Store. The group will show the title for the group name and then the appropriate records for the group underneath. The groups can also be expanded and collapsed. Extra Events This feature adds several extra events that will be fired on the grid to interact with the groups: groupclick groupdblclick groupcontextmenu groupexpand groupcollapse Menu Augmentation This feature adds extra options to the grid column menu to provide the user with functionality to modify the grouping. This can be disabled by setting the enableGroupingMenu option. The option to disallow grouping from being turned off by thew user is enableNoGroups. Controlling Group Text The groupHeaderTpl is used to control the rendered title for each group. It can modified to customized the default display. GroupingSummary|This feature adds an aggregate summary row at the bottom of each group that is provided by the Ext.grid.feature.Grouping feature. There are 2 aspects to the summary: Calculation The summary value needs to be calculated for each column in the grid. This is controlled by the summaryType option specified on the column. There are several built in summary types, which can be specified as a string on the column configuration. These call underlying methods on the store: count sum min max average Alternatively, the summaryType can be a function definition. If this is the case, the function is called with an array of records to calculate the summary value. Rendering Similar to a column, the summary also supports a summaryRenderer function. This summaryRenderer is called before displaying a value. The function is optional, if not specified the default calculated value is shown. The summaryRenderer is called with: value {Object} - The calculated value. summaryData {Object} - Contains all raw summary values for the row. field {String} - The name of the field we are calculating GroupPaging| GroupTabPanel| GroupTabPanelDirectEvents| GroupTabPanelListeners| GuidJsonConverter| HandlerConfig| HasManyAssociation|Represents a one-to-many relationship between two models. Usually created indirectly via a model definition: Ext.regModel('Product', { fields: [ {name: 'id', type: 'int'}, {name: 'userid', type: 'int'}, {name: 'name', type: 'string'} ] }); Ext.regModel('User', { fields: [ {name: 'id', type: 'int'}, {name: 'name', type: 'string'} ], hasMany: {model: 'Product', name: 'products'} }); Above we created Product and User models, and linked them by saying that a User hasMany Products. This gives us a new function on every User instance, in this case the function is called 'products' because that is the name we specified in the association configuration above. This new function returns a specialized Store which is automatically filtered to load only Products for the given model instance: //first, we load up a User with id of 1 var user = Ext.ModelManager.create({id: 1, name: 'Ed'}, 'User'); //the user.products function was created automatically by the association and returns a Store //the created store is automatically scoped to the set of Products for the User with id of 1 var products = user.products(); //we still have all of the usual Store functions, for example it's easy to add a Product for this User products.add({ name: 'Another Product' }); //saves the changes to the store - this automatically sets the new Product's userid to 1 before saving products.sync(); The new Store is only instantiated the first time you call products() to conserve memory and processing time, though calling products() a second time returns the same store instance. Custom filtering The Store is automatically furnished with a filter - by default this filter tells the store to only return records where the associated model's foreign key matches the owner model's primary key. For example, if a User with ID = 100 hasMany Products, the filter loads only Products with userid == 100. Sometimes we want to filter by another field - for example in the case of a Twitter search application we may have models for Search and Tweet: var Search = Ext.regModel('Search', { fields: [ 'id', 'query' ], hasMany: { model: 'Tweet', name : 'tweets', filterProperty: 'query' } }); Ext.regModel('Tweet', { fields: [ 'id', 'text', 'fromuser' ] }); //returns a Store filtered by the filterProperty var store = new Search({query: 'Sencha Touch'}).tweets(); The tweets association above is filtered by the query property by setting the filterProperty, and is equivalent to this: var store = new Ext.data.Store({ model: 'Tweet', filters: [ { property: 'query', value : 'Sencha Touch' } ] }); HasOneAssociation|Represents a one to one association with another model. The owner model is expected to have a foreign key which references the primary key of the associated model: Ext.define('Address', { extend: 'Ext.data.Model', fields: [ { name: 'id', type: 'int' }, { name: 'number', type: 'string' }, { name: 'street', type: 'string' }, { name: 'city', type: 'string' }, { name: 'zip', type: 'string' }, ] }); Ext.define('Person', { extend: 'Ext.data.Model', fields: [ { name: 'id', type: 'int' }, { name: 'name', type: 'string' }, { name: 'addressid', type: 'int'} ], // we can use the hasOne shortcut on the model to create a hasOne association associations: { type: 'hasOne', model: 'Address' } }); In the example above we have created models for People and Addresses, and linked them together by saying that each Person has a single Address. This automatically links each Person to an Address based on the Persons addressid, and provides new functions on the Person model: Generated getter function The first function that is added to the owner model is a getter function: var person = new Person({ id: 100, addressid: 20, name: 'John Smith' }); person.getAddress(function(address, operation) { // do something with the address object alert(address.get('id')); // alerts 20 }, this); The getAddress function was created on the Person model when we defined the association. This uses the Persons configured proxy to load the Address asynchronously, calling the provided callback when it has loaded. The new getAddress function will also accept an object containing success, failure and callback properties - callback will always be called, success will only be called if the associated model was loaded successfully and failure will only be called if the associatied model could not be loaded: person.getAddress({ reload: true, // force a reload if the owner model is already cached callback: function(address, operation) {}, // a function that will always be called success : function(address, operation) {}, // a function that will only be called if the load succeeded failure : function(address, operation) {}, // a function that will only be called if the load did not succeed scope : this // optionally pass in a scope object to execute the callbacks in }); In each case above the callbacks are called with two arguments - the associated model instance and the operation object that was executed to load that instance. The Operation object is useful when the instance could not be loaded. Once the getter has been called on the model, it will be cached if the getter is called a second time. To force the model to reload, specify reload: true in the options object. Generated setter function The second generated function sets the associated model instance - if only a single argument is passed to the setter then the following two calls are identical: // this call... person.setAddress(10); // is equivalent to this call: person.set('addressid', 10); An instance of the owner model can also be passed as a parameter. If we pass in a second argument, the model will be automatically saved and the second argument passed to the owner model's save method: person.setAddress(10, function(address, operation) { // the address has been saved alert(address.get('addressid')); //now alerts 10 }); //alternative syntax: person.setAddress(10, { callback: function(address, operation), // a function that will always be called success : function(address, operation), // a function that will only be called if the load succeeded failure : function(address, operation), // a function that will only be called if the load did not succeed scope : this //optionally pass in a scope object to execute the callbacks in }) Customisation Associations reflect on the models they are linking to automatically set up properties such as the primaryKey and foreignKey. These can alternatively be specified: Ext.define('Person', { fields: [...], associations: [ { type: 'hasOne', model: 'Address', primaryKey: 'uniqueid', foreignKey: 'addrid' } ] }); Here we replaced the default primary key (defaults to 'id') and foreign key (calculated as 'addressid') with our own settings. Usually this will not be needed. HBoxLayoutConfig|A layout that arranges items horizontally across a Container. This layout optionally divides available horizontal space between child items containing a numeric flex configuration. This layout may also be used to set the heights of child items by configuring it with the align option. Hidden| Highlight| HighlightConfig| History| HistoryDirectEvents| HistoryListeners| Html| HtmlEditor| HtmlEditorButtonTip| HtmlEditorButtonTips| HtmlEditorDirectEvents| HtmlEditorListeners| HyperLink| Image| ImageBase| ImageButton| ImageCommand| ImageCommandBase| ImageCommandCollection| ImageCommandColumn| ImageCommandColumnDirectEvents| ImageCommandColumnListeners| ImageDirectEvents| ImageListeners| InclusionValidation|Validates that the given value is present in the configured list InitializationScriptNotFoundException| InitScriptFilter| InlineEditorDirectEvents| InlineEditorListeners| InputFieldsTag| InputMask| InsertOrderedDictionary<TKey, TValue>| IntArrayJsonConverter| ISODateTimeJsonConverter|Converts a System.DateTime to and from the ISO 8601 date format (e.g. 2008-04-12T12:53Z). ItemCollection| ItemCollectionEditor| ItemCollectionJsonConverter| ItemsBuilder<TParent, TParentBuilder>| ItemsCollection<T>| ItemSelector|A control that allows selection of between two MultiSelect controls. ItemSelectorButtonsText| ItemState| JFunction| JFunctionJsonConverter| JRawValue| JRawValueJsonConverter| Js|JavaScript helper functions. JSON|Convenience wrappers for Json.NET JSONDateTimeJsonConverter|Converts a System.DateTime to and from the ISO 8601 date format (e.g. 2008-04-12T12:53) using the server time. Does not adjust for timezone. JsonObject| JsonPProxy| JsonReader|The JSON Reader is used by a Proxy to read a server response that is sent back in JSON format. This usually happens as a result of loading a Store - for example we might create something like this: Ext.regModel('User', { fields: ['id', 'name', 'email'] }); var store = new Ext.data.Store({ model: 'User', proxy: { type: 'ajax', url : 'users.json', reader: { type: 'json' } } }); The example above creates a 'User' model. Models are explained in the Model docs if you're not already familiar with them. We created the simplest type of JSON Reader possible by simply telling our Store's Proxy that we want a JSON Reader. The Store automatically passes the configured model to the Store, so it is as if we passed this instead: reader: { type : 'json', model: 'User' } The reader we set up is ready to read data from our server - at the moment it will accept a response like this: [ { "id": 1, "name": "Ed Spencer", "email": "ed@sencha.com" }, { "id": 2, "name": "Abe Elias", "email": "abe@sencha.com" } ] Reading other JSON formats If you already have your JSON format defined and it doesn't look quite like what we have above, you can usually pass JsonReader a couple of configuration options to make it parse your format. For example, we can use the root configuration to parse data that comes back like this: { "users": [ { "id": 1, "name": "Ed Spencer", "email": "ed@sencha.com" }, { "id": 2, "name": "Abe Elias", "email": "abe@sencha.com" } ] } To parse this we just pass in a root configuration that matches the 'users' above: reader: { type: 'json', root: 'users' } Sometimes the JSON structure is even more complicated. Document databases like CouchDB often provide metadata around each record inside a nested structure like this: { "total": 122, "offset": 0, "users": [ { "id": "ed-spencer-1", "value": 1, "user": { "id": 1, "name": "Ed Spencer", "email": "ed@sencha.com" } } ] } In the case above the record data is nested an additional level inside the "users" array as each "user" item has additional metadata surrounding it ('id' and 'value' in this case). To parse data out of each "user" item in the JSON above we need to specify the record configuration like this: reader: { type : 'json', root : 'users', record: 'user' } Response metadata The server can return additional data in its response, such as the total number of records and the success status of the response. These are typically included in the JSON response like this: { "total": 100, "success": true, "users": [ { "id": 1, "name": "Ed Spencer", "email": "ed@sencha.com" } ] } If these properties are present in the JSON response they can be parsed out by the JsonReader and used by the Store that loaded it. We can set up the names of these properties by specifying a final pair of configuration options: reader: { type : 'json', root : 'users', totalProperty : 'total', successProperty: 'success' } These final options are not necessary to make the Reader work, but can be useful when the server needs to report an error or if it needs to indicate that there is a lot of data available of which only a subset is currently being returned. JsonWriter|Writer that outputs model data in JSON format Key| KeyBinding| KeyBindingCollection| KeyCollection| KeyMap| KeyNav| Label| Labelable| LabelBase|Produces a standalone element which can be inserted into a form and be associated with a field in that form using the forId property. NOTE: in most cases it will be more appropriate to use the fieldLabel and associated config properties (Ext.form.Labelable.labelAlign, Ext.form.Labelable.labelWidth, etc.) in field components themselves, as that allows labels to be uniformly sized throughout the form. Ext.form.Label should only be used when your layout can not be achieved with the standard field layout. You will likely be associating the label with a field component that extends Ext.form.field.Base, so you should make sure the forId is set to the same value as the inputId of that field. The label's text can be set using either the text or html configuration properties; the difference between the two is that the former will automatically escape HTML characters when rendering, while the latter will not. Layer|An extended Ext.Element object that supports a shadow and shim, constrain to viewport and automatic maintaining of shadow/shim positions. LayerConfig| LayoutConfig| LayoutConfigCollection| LayoutConverter| LazyControlJsonConverter| LazyObservable| LengthValidation|Returns true if the given value is between the configured min and max values LineSeries|Creates a Line Chart. A Line Chart is a useful visualization technique to display quantitative information for different categories or other real values (as opposed to the bar chart), that can show some progression (or regression) in the dataset. As with all other series, the Line Series must be appended in the series Chart array configuration. Note: In the series definition remember to explicitly set the axis to bind the values of the line series to. This can be done by using the axis configuration property. LinkButton| LinkedScriptTag| Listener| ListenerArgumentAttribute| ListenerCollection| ListenerJsonConverter| ListenerPropertyInfo| ListenersConverter| ListenerTriplet| ListFilter| ListItem| ListItemCollection| ListItemCollectionJsonConverter| LiveSearchGridPanel| LiveSearchGridPanelDirectEvents| LiveSearchGridPanelListeners| LiveSearchToolbar| LoadConfig| LoadMask| LoadMaskJsonConverter| LocalStorageProxy|The LocalStorageProxy uses the new HTML5 localStorage API to save Model data locally on the client browser. HTML5 localStorage is a key-value store (e.g. cannot save complex objects like JSON), so LocalStorageProxy automatically serializes and deserializes data when saving and retrieving it. localStorage is extremely useful for saving user-specific information without needing to build server-side infrastructure to support it. Let's imagine we're writing a Twitter search application and want to save the user's searches locally so they can easily perform a saved search again later. We'd start by creating a Search model: Ext.regModel('Search', { fields: ['id', 'query'], proxy: { type: 'localstorage', id : 'twitter-Searches' } }); Our Search model contains just two fields - id and query - plus a Proxy definition. The only configuration we need to pass to the LocalStorage proxy is an id. This is important as it separates the Model data in this Proxy from all others. The localStorage API puts all data into a single shared namespace, so by setting an id we enable LocalStorageProxy to manage the saved Search data. Saving our data into localStorage is easy and would usually be done with a Store: //our Store automatically picks up the LocalStorageProxy defined on the Search model var store = new Ext.data.Store({ model: "Search" }); //loads any existing Search data from localStorage store.load(); //now add some Searches store.add({query: 'Sencha Touch'}); store.add({query: 'Ext JS'}); //finally, save our Search data to localStorage store.sync(); The LocalStorageProxy automatically gives our new Searches an id when we call store.sync(). It encodes the Model data and places it into localStorage. We can also save directly to localStorage, bypassing the Store altogether: var search = Ext.ModelManager.create({query: 'Sencha Animator'}, 'Search'); //uses the configured LocalStorageProxy to save the new Search to localStorage search.save(); Limitations If this proxy is used in a browser where local storage is not supported, the constructor will throw an error. A local storage proxy requires a unique ID which is used as a key in which all record data are stored in the local storage object. It's important to supply this unique ID as it cannot be reliably determined otherwise. If no id is provided but the attached store has a storeId, the storeId will be used. If neither option is presented the proxy will throw an error. Margins|An object containing margins to apply to the region when in the expanded state. MarginsJsonConverter| Mask| MaskConfig|A config object containing any or all of the following properties. If this object is not specified the status will be cleared using the defaults. MaskSymbol| MaskSymbolCollection| Menu| MenuBase| MenuCollection| MenuCollectionBuilder<TParent, TParentBuilder>| MenuCommand| MenuCommandCollection| MenuDirectEvents| MenuItem| MenuItemBase| MenuItemBaseMenuCollectionBuilder<TParent, TParentBuilder>| MenuItemDirectEvents| MenuItemListeners| MenuListeners| MenuPanel| MenuSeparator| MessageBox| MessageBoxButtonConfig| MessageBoxButtonsConfig| MessageBoxButtonTextConfig| MessageBoxConfig| MessageBus|See http://www.openajax.org/member/wiki/OpenAjaxHub2.0Specification http://www.openajax.org/member/wiki/OpenAjaxHub2.0SpecificationTopicNames MessageBusDirectEvent| MessageBusDirectEvents| MessageBusListener| MessageBusListeners| MetaAttribute| MetaConfig|The server can return metadata in its response, in addition to the record data, that describe attributes of the data set itself or are used to reconfigure the Reader. To pass metadata in the response you simply add a metaData attribute to the root of the response data. The metaData attribute can contain anything, but supports a specific set of properties that are handled by the Reader if they are present: root: the property name of the root response node containing the record data idProperty: property name for the primary key field of the data totalProperty: property name for the total number of records in the data successProperty: property name for the success status of the response messageProperty: property name for an optional response message fields: Config used to reconfigure the Model's fields before converting the response data into records The Reader will automatically read the meta fields config and rebuild the Model based on the new fields, but to handle the new column configuration you would need to handle the metadata within the application code. This is done simply enough by handling the metachange event on either the store or the proxy Model|A Model represents some object that your application manages. For example, one might define a Model for Users, Products, Cars, or any other real-world object that we want to model in the system. Models are registered via the model manager, and are used by stores, which are in turn used by many of the data-bound components in Ext. Models are defined as a set of fields and any arbitrary methods and properties relevant to the model. For example: Ext.regModel('User', { fields: [ {name: 'name', type: 'string'}, {name: 'age', type: 'int'}, {name: 'phone', type: 'string'}, {name: 'alive', type: 'boolean', defaultValue: true} ], changeName: function() { var oldName = this.get('name'), newName = oldName + " The Barbarian"; this.set('name', newName); } }); The fields array is turned into a MixedCollection automatically by the ModelManager, and all other functions and properties are copied to the new Model's prototype. Now we can create instances of our User model and call any model logic we defined: var user = Ext.ModelManager.create({ name : 'Conan', age : 24, phone: '555-555-5555' }, 'User'); user.changeName(); user.get('name'); //returns "Conan The Barbarian" Validations Models have built-in support for validations, which are executed against the validator functions in Ext.data.validations (see all validation functions). Validations are easy to add to models: Ext.regModel('User', { fields: [ {name: 'name', type: 'string'}, {name: 'age', type: 'int'}, {name: 'phone', type: 'string'}, {name: 'gender', type: 'string'}, {name: 'username', type: 'string'}, {name: 'alive', type: 'boolean', defaultValue: true} ], validations: [ {type: 'presence', field: 'age'}, {type: 'length', field: 'name', min: 2}, {type: 'inclusion', field: 'gender', list: ['Male', 'Female']}, {type: 'exclusion', field: 'username', list: ['Admin', 'Operator']}, {type: 'format', field: 'username', matcher: /([a-z]+)[0-9]{2,3}/} ] }); The validations can be run by simply calling the validate function, which returns a Ext.data.Errors object: var instance = Ext.ModelManager.create({ name: 'Ed', gender: 'Male', username: 'edspencer' }, 'User'); var errors = instance.validate(); Associations Models can have associations with other Models via belongsTo and hasMany associations. For example, let's say we're writing a blog administration application which deals with Users, Posts and Comments. We can express the relationships between these models like this: Ext.regModel('Post', { fields: ['id', 'userid'], belongsTo: 'User', hasMany : {model: 'Comment', name: 'comments'} }); Ext.regModel('Comment', { fields: ['id', 'userid', 'postid'], belongsTo: 'Post' }); Ext.regModel('User', { fields: ['id'], hasMany: [ 'Post', {model: 'Comment', name: 'comments'} ] }); See the docs for Ext.data.BelongsToAssociation and Ext.data.HasManyAssociation for details on the usage and configuration of associations. Note that associations can also be specified like this: Ext.regModel('User', { fields: ['id'], associations: [ {type: 'hasMany', model: 'Post', name: 'posts'}, {type: 'hasMany', model: 'Comment', name: 'comments'} ] }); Using a Proxy Models are great for representing types of data and relationships, but sooner or later we're going to want to load or save that data somewhere. All loading and saving of data is handled via a Proxy, which can be set directly on the Model: Ext.regModel('User', { fields: ['id', 'name', 'email'], proxy: { type: 'rest', url : '/users' } }); Here we've set up a Rest Proxy, which knows how to load and save data to and from a RESTful backend. Let's see how this works: var user = Ext.ModelManager.create({name: 'Ed Spencer', email: 'ed@sencha.com'}, 'User'); user.save(); //POST /users Calling save on the new Model instance tells the configured RestProxy that we wish to persist this Model's data onto our server. RestProxy figures out that this Model hasn't been saved before because it doesn't have an id, and performs the appropriate action - in this case issuing a POST request to the url we configured (/users). We configure any Proxy on any Model and always follow this API - see Ext.data.proxy.Proxy for a full list. Loading data via the Proxy is equally easy: //get a reference to the User model class var User = Ext.ModelManager.getModel('User'); //Uses the configured RestProxy to make a GET request to /users/123 User.load(123, { success: function(user) { console.log(user.getId()); //logs 123 } }); Models can also be updated and destroyed easily: //the user Model we loaded in the last snippet: user.set('name', 'Edward Spencer'); //tells the Proxy to save the Model. In this case it will perform a PUT request to /users/123 as this Model already has an id user.save({ success: function() { console.log('The User was updated'); } }); //tells the Proxy to destroy the Model. Performs a DELETE request to /users/123 user.destroy({ success: function() { console.log('The User was destroyed!'); } }); Usage in Stores It is very common to want to load a set of Model instances to be displayed and manipulated in the UI. We do this by creating a Store: var store = new Ext.data.Store({ model: 'User' }); //uses the Proxy we set up on Model to load the Store data store.load(); A Store is just a collection of Model instances - usually loaded from a server somewhere. Store can also maintain a set of added, updated and removed Model instances to be synchronized with the server via the Proxy. See the Store docs for more information on Stores. ModelCollection| ModelField|Fields are used to define what a Model is. They aren't instantiated directly - instead, when we create a class that extends Ext.data.Model, it will automatically create a Field instance for each field configured in a Model. For example, we might set up a model like this: Ext.define('User', { extend: 'Ext.data.Model', fields: [ 'name', 'email', {name: 'age', type: 'int'}, {name: 'gender', type: 'string', defaultValue: 'Unknown'} ] }); Four fields will have been created for the User Model - name, email, age and gender. Note that we specified a couple of different formats here; if we only pass in the string name of the field (as with name and email), the field is set up with the 'auto' type. It's as if we'd done this instead: Ext.define('User', { extend: 'Ext.data.Model', fields: [ {name: 'name', type: 'auto'}, {name: 'email', type: 'auto'}, {name: 'age', type: 'int'}, {name: 'gender', type: 'string', defaultValue: 'Unknown'} ] }); Types and conversion The type is important - it's used to automatically convert data passed to the field into the correct format. In our example above, the name and email fields used the 'auto' type and will just accept anything that is passed into them. The 'age' field had an 'int' type however, so if we passed 25.4 this would be rounded to 25. Sometimes a simple type isn't enough, or we want to perform some processing when we load a Field's data. We can do this using a convert function. Here, we're going to create a new field based on another: Ext.define('User', { extend: 'Ext.data.Model', fields: [ 'name', 'email', {name: 'age', type: 'int'}, {name: 'gender', type: 'string', defaultValue: 'Unknown'}, { name: 'firstName', convert: function(value, record) { var fullName = record.get('name'), splits = fullName.split(" "), firstName = splits[0]; return firstName; } } ] }); Now when we create a new User, the firstName is populated automatically based on the name: var ed = Ext.create('User', {name: 'Ed Spencer'}); console.log(ed.get('firstName')); //logs 'Ed', based on our convert function In fact, if we log out all of the data inside ed, we'll see this: console.log(ed.data); //outputs this: { age: 0, email: "", firstName: "Ed", gender: "Unknown", name: "Ed Spencer" } The age field has been given a default of zero because we made it an int type. As an auto field, email has defaulted to an empty string. When we registered the User model we set gender's defaultValue to 'Unknown' so we see that now. Let's correct that and satisfy ourselves that the types work as we expect: ed.set('gender', 'Male'); ed.get('gender'); //returns 'Male' ed.set('age', 25.4); ed.get('age'); //returns 25 - we wanted an int, not a float, so no decimal places allowed ModelFieldCollection| ModelIdGenerator|This class is a base for all id generators. It also provides lookup of id generators by their id. Generally, id generators are used to generate a primary key for new model instances. There are different approaches to solving this problem, so this mechanism has both simple use cases and is open to custom implementations. A Ext.data.Model requests id generation using the Ext.data.Model.idgen property. ModelIdGeneratorCollection| ModelProxy|Class for model instance manipulation ModelSerializer| MonthPicker|A month picker component. This class is used by the Date picker class to allow browsing and selection of year/months combinations. MonthPickerDirectEvents| MonthPickerListeners| MonthView|Displays a calendar view by month. This class does not usually need ot be used directly as you can use a CalendarPanel to manage multiple calendar views at once including the month view. MonthViewBase| MonthViewDirectEvents| MonthViewListeners| MouseDistanceSensor| MouseDistanceSensorDirectEvents| MouseDistanceSensorListeners| MultiCombo| MultiSelect| MultiSelectBase| MultiSelectDirectEvents| MultiSelectionModelDirectEvents| MultiSelectionModelListeners| MultiSelectListeners| MultiUpload| MultiUploadDirectEvents| MultiUploadListeners| NetToPHPDateFormatStringJsonConverter| NetTypeConverter| Node| NodeBinding| NodeBindingCollection| NodeCollection| NodeDirectEvents| NodeListeners| NodeLoadEventArgs| NodeProxy|Class for node instance manipulation Notification| NotificationAlignConfig| NotificationConfig| NumberColumn| NumberField| NumberFieldBase| NumberFieldDirectEvents| NumberFieldListeners| NumericAxis|An axis to handle numeric values. This axis is used for quantitative data as opposed to the category axis. You can set mininum and maximum values to the axis so that the values are bound to that. If no values are set, then the scale will auto-adjust to the values. NumericFilter| ObjectComparer|Utility class for comparing objects. ObjectHolder| Observable| ObservableDirectEvent| ODataProxy| ODataReader| Paddings| PageProxy| Paging<T>| PagingToolbar| PagingToolbarDirectEvents| PagingToolbarListeners| Panel| PanelDirectEvents| PanelHeader|Simple header class which is used for on Ext.panel.Panel and Ext.window.Window. PanelHeaderDirectEvents| PanelHeaderListeners| PanelListeners| Parameter| ParameterCollection| PasswordMask| PickerField|An abstract class for fields that have a single trigger which opens a "picker" popup below the field, e.g. a combobox menu list or a date picker. It provides a base implementation for toggling the picker's visibility when the trigger is clicked, as well as keyboard navigation and some basic events. Sizing and alignment of the picker can be controlled via the matchFieldWidth and pickerAlign/pickerOffset config properties respectively. You would not normally use this class directly, but instead use it as the parent class for a specific picker field implementation. Subclasses must implement the createPicker method to create a picker component appropriate for the field. PickerFieldDirectEvents| PickerFieldListeners| PieSeries|Creates a Pie Chart. A Pie Chart is a useful visualization technique to display quantitative information for different categories that also have a meaning as a whole. As with all other series, the Pie Series must be appended in the series Chart array configuration. Plugin| Portal| PortalColumn| PortalDirectEvents| PortalListeners| Portlet| PresenceValidation|Validates that the given value is present Preview| ProgressBar| ProgressBarColumn| ProgressBarDirectEvents| ProgressBarListeners| ProgressBarPager| PropertyGrid| PropertyGridDirectEvents| PropertyGridListeners| PropertyGridParameter| PropertyGridParameterCollection| ProxyCollection| ProxyListeners| Puff| QTipCfg| QuickTips| RadarSeries|Creates a Radar Chart. A Radar Chart is a useful visualization technique for comparing different quantitative values for a constrained number of categories. As with all other series, the Radar series must be appended in the series Chart array configuration. RadialAxis| Radio| RadioDirectEvents| RadioGroup| RadioListeners| RatingColumn| ReaderCollection| RecordModifiedEventArgs| RecordsToXmlConverter| RegexJsonConverter| ReminderCombo|A custom combo used for choosing a reminder setting for an event. This is pretty much a standard combo that is simply pre-configured for the options needed by the calendar components. RemoteActionEventArgs| RemoteAppendEventArgs| RemoteEditEventArgs| RemoteMoveEventArgs| RemoteRemoveEventArgs| RemoteValidationDirectEvent| RemoteValidationEventArgs| Renderer| RendererJsonConverter| RequestManager| ResizableDirectEvents| ResizableListeners| Resizer| ResourceDescriptor| ResourceItem| ResourceManager| ResourceManagerDirectEvents| ResourceManagerListeners| ResourcePlaceHolder|Simple Container Control to allow for custom placement of Scripts and Styles in the <head> of the Page by the ResourceManager. If the Page does not contain a <ext:ResourcePlaceHolder> control, the <script>'s and <style>'s will be added as the last items in the <head>. The ResourceContainer does not render any HTML to the Page. ResourcesRegistrator| ResourcesStrategy| Response| ResponseManager| ResponseRecordsList| RestProxy|RestProxy is a specialization of the AjaxProxy which simply maps the four actions (create, read, update and destroy) to RESTful HTTP verbs. For example, let's set up a Model with an inline RestProxy Ext.regModel('User', { fields: ['id', 'name', 'email'], proxy: { type: 'rest', url : '/users' } }); Now we can create a new User instance and save it via the RestProxy. Doing this will cause the Proxy to send a POST request to '/users': var user = Ext.ModelManager.create({name: 'Ed Spencer', email: 'ed@sencha.com'}, 'User'); user.save(); //POST /users Let's expand this a little and provide a callback for the Ext.data.Model.save call to update the Model once it has been created. We'll assume the creation went successfully and that the server gave this user an ID of 123: user.save({ success: function(user) { user.set('name', 'Khan Noonien Singh'); user.save(); //PUT /users/123 } }); Now that we're no longer creating a new Model instance, the request method is changed to an HTTP PUT, targeting the relevant url for that user. Now let's delete this user, which will use the DELETE method: user.destroy(); //DELETE /users/123 Finally, when we perform a load of a Model or Store, RestProxy will use the GET method: //1. Load via Store //the Store automatically picks up the Proxy from the User model var store = new Ext.data.Store({ model: 'User' }); store.load(); //GET /users //2. Load directly from the Model //GET /users/123 Ext.ModelManager.getModel('User').load(123, { success: function(user) { console.log(user.getId()); //outputs 123 } }); Url generation RestProxy is able to automatically generate the urls above based on two configuration options - appendId and format. If appendId is true (it is by default) then RestProxy will automatically append the ID of the Model instance in question to the configured url, resulting in the '/users/123' that we saw above. If the request is not for a specific Model instance (e.g. loading a Store), the url is not appended with an id. RestProxy will automatically insert a '/' before the ID if one is not already present. new Ext.data.proxy.Rest({ url: '/users', appendId: true //default }); // Collection url: /users // Instance url : /users/123 RestProxy can also optionally append a format string to the end of any generated url: new Ext.data.proxy.Rest({ url: '/users', format: 'json' }); // Collection url: /users.json // Instance url : /users/123.json If further customization is needed, simply implement the buildUrl method and add your custom generated url onto the Request object that is passed to buildUrl. See RestProxy's implementation for an example of how to achieve this. Note that RestProxy inherits from AjaxProxy, which already injects all of the sorter, filter, group and paging options into the generated url. See the AjaxProxy docs for more details. RotateAttribute| RowBody|The rowbody feature enhances the grid's markup to have an additional tr -> td -> div which spans the entire width of the original row. This is useful to to associate additional information with a particular record in a grid. Rowbodies are initially hidden unless you override getAdditionalData. Will expose additional events on the gridview with the prefix of 'rowbody'. For example: 'rowbodyclick', 'rowbodydblclick', 'rowbodycontextmenu'. RowChanges| RowEditing|The Ext.grid.plugin.RowEditing plugin injects editing at a row level for a Grid. When editing begins, a small floating dialog will be shown for the appropriate row. Each editable column will show a field for editing. There is a button to save or cancel all changes for the edit. The field that will be used for the editor is defined at the editor. The editor can be a field instance or a field configuration. If an editor is not specified for a particular column then that column won't be editable and the value of the column will be displayed. To provide a custom renderer for non-editable values, use the editRenderer configuration on the column. The editor may be shared for each column in the grid, or a different one may be specified for each column. An appropriate field type should be chosen to match the data structure that it will be editing. For example, to edit a date, it would be useful to specify Ext.form.field.Date as the editor. RowEditingDirectEvents| RowEditingListeners| RowEditorDirectEvents| RowEditorListeners| RowExpander| RowExpanderDirectEvents| RowExpanderListeners| RowNumbererColumn| RowSelectionModel|Implement row based navigation via keyboard. Must synchronize across grid sections RowSelectionModelDirectEvents| RowSelectionModelListeners| RowWrap| Scale| ScaleAttribute| ScatterSeries|Creates a Scatter Chart. The scatter plot is useful when trying to display more than two variables in the same visualization. These variables can be mapped into x, y coordinates and also to an element's radius/size, color, etc. As with all other series, the Scatter Series must be appended in the series Chart array configuration. ScriptClass| SelectBox|Makes a ComboBox more closely mimic an HTML SELECT. Supports clicking and dragging through the list, with item selection occurring when the mouse button is released. When used will automatically set editable to false and call unselectable on inner elements. Re-enabling editable after calling this will NOT work. SelectedCell| SelectedCellSerializable| SelectedListItem| SelectedListItemCollection| SelectedRow| SelectedRowCollection| SelectionModelCollection| SelfRenderingPage| SequentialIdGenerator|This class is a sequential id generator. SerializationOptions| SeriesCollection| SeriesLabel| SeriesListeners| ServerProxy|ServerProxy is a superclass of JsonPProxy and AjaxProxy, and would not usually be used directly. ServiceMessages| SessionStorageProxy|Proxy which uses HTML5 session storage as its data storage/retrieval mechanism. If this proxy is used in a browser where session storage is not supported, the constructor will throw an error. A session storage proxy requires a unique ID which is used as a key in which all record data are stored in the session storage object. It's important to supply this unique ID as it cannot be reliably determined otherwise. If no id is provided but the attached store has a storeId, the storeId will be used. If neither option is presented the proxy will throw an error. Proxies are almost always used with a store: new Ext.data.Store({ proxy: { type: 'sessionstorage', id : 'myProxyKey' } }); Alternatively you can instantiate the Proxy directly: new Ext.data.proxy.SessionStorage({ id : 'myOtherProxyKey' }); Note that session storage is different to local storage (see Ext.data.proxy.LocalStorage) - if a browser session is ended (e.g. by closing the browser) then all data in a SessionStorageProxy are lost. Browser restarts don't affect the Ext.data.proxy.LocalStorage - the data are preserved. ShadowJsonConverter| Shift| ShiftConfig| ShortcutDefaults| SimpleListener| SimpleToolTip| SingleItemCollection<T>| SingleItemCollectionJsonConverter| SingleItemStateCollection<T>| SingleStringArrayJsonConverter| SlideIn| SlideOut| Slider|Slider which supports vertical or horizontal orientation, keyboard adjustments, configurable snapping, axis clicking and animation. Sliders can be created with more than one thumb handle by passing an array of values instead of a single one SliderBase| SliderDirectEvents| SliderListeners| SliderTip|Simple plugin for using an Ext.Tip with a slider to show the slider value. SlidingPager| SortInfo|A config object in the format: {field: 'fieldName', direction: 'ASC|DESC'}. The direction property is case-sensitive. SpinnerField|A field with a pair of up/down spinner buttons. This class is not normally instantiated directly, instead it is subclassed and the onSpinUp and onSpinDown methods are implemented to handle when the buttons are clicked. A good example of this is the Ext.form.field.Number field which uses the spinner to increment and decrement the field's value by its step config value. SpinnerFieldBase|A field with a pair of up/down spinner buttons. This class is not normally instantiated directly, instead it is subclassed and the onSpinUp and onSpinDown methods are implemented to handle when the buttons are clicked. A good example of this is the Ext.form.field.Number field which uses the spinner to increment and decrement the field's value by its step config value. SpinnerFieldDirectEvents| SpinnerFieldListeners| SplitButton| SplitButtonBase| SplitButtonDirectEvents| SplitButtonListeners| SplitCommand| Spotlight| Sprite|A Sprite is an object rendered in a Drawing surface. Translation For translate, the configuration object contains x and y attributes that indicate where to translate the object. For example: sprite.setAttributes({ translate: { x: 10, y: 10 } }, true); Rotation For rotation, the configuration object contains x and y attributes for the center of the rotation (which are optional), and a degrees attribute that specifies the rotation in degrees. For example: sprite.setAttributes({ rotate: { degrees: 90 } }, true); That example will create a 90 degrees rotation using the centroid of the Sprite as center of rotation, whereas: sprite.setAttributes({ rotate: { x: 0, y: 0, degrees: 90 } }, true); will create a rotation around the (0, 0) axis. Scaling For scaling, the configuration object contains x and y attributes for the x-axis and y-axis scaling. For example: sprite.setAttributes({ scale: { x: 10, y: 3 } }, true); You can also specify the center of scaling by adding cx and cy as properties: sprite.setAttributes({ scale: { cx: 0, cy: 0, x: 10, y: 3 } }, true); That last example will scale a sprite taking as centers of scaling the (0, 0) coordinate. Creating and adding a Sprite to a Surface Sprites can be created with a reference to a Ext.draw.Surface var drawComponent = Ext.create('Ext.draw.Component', options here...); var sprite = Ext.create('Ext.draw.Sprite', { type: 'circle', fill: '#ff0', surface: drawComponent.surface, radius: 5 }); Sprites can also be added to the surface as a configuration object: var sprite = drawComponent.surface.add({ type: 'circle', fill: '#ff0', radius: 5 }); In order to properly apply properties and render the sprite we have to show the sprite setting the option redraw to true: sprite.show(true); The constructor configuration object of the Sprite can also be used and passed into the Ext.draw.Surface add method to append a new sprite to the canvas. For example: drawComponent.surface.add({ type: 'circle', fill: '#ffc', radius: 100, x: 100, y: 100 }); SpriteAttributes| SpriteAttributesCollection| SpriteCollection| SpriteListeners| StartupMask| StatusBar| StatusBarClearConfig| StatusBarClearStatusConfig| StatusBarDirectEvents| StatusBarListeners| StatusBarStatusConfig| Store|The Store class encapsulates a client side cache of Record objects which provide input data for Components such as the GridPanel, the ComboBox, or the DataView A Store object uses its configured implementation of DataProxy to access a data object unless you call loadData directly and pass in your data. A Store object has no knowledge of the format of the data returned by the Proxy. A Store object uses its configured implementation of DataReader to create Record instances from the data object. These Records are cached and made available through accessor functions. StoreBase|The Store class encapsulates a client side cache of Model objects. Stores load data via a Proxy, and also provide functions for sorting, filtering and querying the model instances contained within it. Creating a Store is easy - we just tell it the Model and the Proxy to use to load and save its data: // Set up a model to use in our Store Ext.define('User', { extend: 'Ext.data.Model', fields: [ {name: 'firstName', type: 'string'}, {name: 'lastName', type: 'string'}, {name: 'age', type: 'int'}, {name: 'eyeColor', type: 'string'} ] }); var myStore = new Ext.data.Store({ model: 'User', proxy: { type: 'ajax', url : '/users.json', reader: { type: 'json', root: 'users' } }, autoLoad: true }); In the example above we configured an AJAX proxy to load data from the url '/users.json'. We told our Proxy to use a JsonReader to parse the response from the server into Model object - see the docs on JsonReader for details. Inline data Stores can also load data inline. Internally, Store converts each of the objects we pass in as data into Model instances: new Ext.data.Store({ model: 'User', data : [ {firstName: 'Ed', lastName: 'Spencer'}, {firstName: 'Tommy', lastName: 'Maintz'}, {firstName: 'Aaron', lastName: 'Conran'}, {firstName: 'Jamie', lastName: 'Avins'} ] }); Loading inline data using the method above is great if the data is in the correct format already (e.g. it doesn't need to be processed by a reader). If your inline data requires processing to decode the data structure, use a MemoryProxy instead (see the MemoryProxy docs for an example). Additional data can also be loaded locally using add. Loading Nested Data Applications often need to load sets of associated data - for example a CRM system might load a User and her Orders. Instead of issuing an AJAX request for the User and a series of additional AJAX requests for each Order, we can load a nested dataset and allow the Reader to automatically populate the associated models. Below is a brief example, see the Ext.data.reader.Reader intro docs for a full explanation: var store = new Ext.data.Store({ autoLoad: true, model: "User", proxy: { type: 'ajax', url : 'users.json', reader: { type: 'json', root: 'users' } } }); Which would consume a response like this: { "users": [ { "id": 1, "name": "Ed", "orders": [ { "id": 10, "total": 10.76, "status": "invoiced" }, { "id": 11, "total": 13.45, "status": "shipped" } ] } ] } See the Ext.data.reader.Reader intro docs for a full explanation. Filtering and Sorting Stores can be sorted and filtered - in both cases either remotely or locally. The sorters and filters are held inside MixedCollection instances to make them easy to manage. Usually it is sufficient to either just specify sorters and filters in the Store configuration or call sort or filter: var store = new Ext.data.Store({ model: 'User', sorters: [ { property : 'age', direction: 'DESC' }, { property : 'firstName', direction: 'ASC' } ], filters: [ { property: 'firstName', value : /Ed/ } ] }); The new Store will keep the configured sorters and filters in the MixedCollection instances mentioned above. By default, sorting and filtering are both performed locally by the Store - see remoteSort and remoteFilter to allow the server to perform these operations instead. Filtering and sorting after the Store has been instantiated is also easy. Calling filter adds another filter to the Store and automatically filters the dataset (calling filter with no arguments simply re-applies all existing filters). Note that by default sortOnFilter is set to true, which means that your sorters are automatically reapplied if using local sorting. store.filter('eyeColor', 'Brown'); Change the sorting at any time by calling sort: store.sort('height', 'ASC'); Note that all existing sorters will be removed in favor of the new sorter data (if sort is called with no arguments, the existing sorters are just reapplied instead of being removed). To keep existing sorters and add new ones, just add them to the MixedCollection: store.sorters.add(new Ext.util.Sorter({ property : 'shoeSize', direction: 'ASC' })); store.sort(); Registering with StoreManager Any Store that is instantiated with a storeId will automatically be registed with the StoreManager. This makes it easy to reuse the same store in multiple views: //this store can be used several times new Ext.data.Store({ model: 'User', storeId: 'usersStore' }); new Ext.List({ store: 'usersStore', //other config goes here }); new Ext.view.View({ store: 'usersStore', //other config goes here }); Further Reading Stores are backed up by an ecosystem of classes that enables their operation. To gain a full understanding of these pieces and how they fit together, see: Proxy - overview of what Proxies are and how they are used Model - the core class in the data package Reader - used by any subclass of ServerProxy to read a response StoreCollection<T>| StoreDataHandler| StoreDirectEvents| StoreListeners| StoreNotFoundException| StoreParameter| StoreParameterCollection| StoreReadDataEventArgs| StoreRequestParameters| StoreResponseData| StoreSubmitDataEventArgs| StringArrayJsonConverter| StringFilter| SubmitEventArgs| SubmitHandler| SubmittedNode| Summary|This feature is used to place a summary row at the bottom of the grid. If using a grouping, see Ext.grid.feature.GroupingSummary. There are 2 aspects to calculating the summaries, calculation and rendering. Calculation The summary value needs to be calculated for each column in the grid. This is controlled by the summaryType option specified on the column. There are several built in summary types, which can be specified as a string on the column configuration. These call underlying methods on the store: count sum min max average Alternatively, the summaryType can be a function definition. If this is the case, the function is called with an array of records to calculate the summary value. Rendering Similar to a column, the summary also supports a summaryRenderer function. This summaryRenderer is called before displaying a value. The function is optional, if not specified the default calculated value is shown. The summaryRenderer is called with: value {Object} - The calculated value. summaryData {Object} - Contains all raw summary values for the row. field {String} - The name of the field we are calculating SummaryColumn| SwitchOff| SyncStoreBase| Tab| TabCloseMenu|Very simple plugin for adding a close context menu to tabs TabFx| TableLayoutConfig|This layout allows you to easily render content into an HTML table. The total number of columns can be specified, and rowspan and colspan can be used to create complex layouts within the table. This class is intended to be extended or created via the layout: {type: 'table'} Ext.container.Container-layout config, and should generally not need to be created directly via the new keyword. Note that when creating a layout via config, the layout-specific config properties must be passed in via the Ext.container.Container-layout object which will then be applied internally to the layout. In the case of TableLayout, the only valid layout config properties are columns and tableAttrs. However, the items added to a TableLayout can supply the following table-specific config properties: rowspan Applied to the table cell containing the item. colspan Applied to the table cell containing the item. cellId An id applied to the table cell containing the item. cellCls A CSS class name added to the table cell containing the item. The basic concept of building up a TableLayout is conceptually very similar to building up a standard HTML table. You simply add each panel (or "cell") that you want to include along with any span attributes specified as the special config properties of rowspan and colspan which work exactly like their HTML counterparts. Rather than explicitly creating and nesting rows and columns as you would in HTML, you simply specify the total column count in the layoutConfig and start adding panels in their natural order from left to right, top to bottom. The layout will automatically figure out, based on the column count, rowspans and colspans, how to position each panel within the table. Just like with HTML tables, your rowspans and colspans must add up correctly in your overall layout or you'll end up with missing and/or extra cells! TablePanel|TablePanel is the basis of both TreePanel and GridPanel. TablePanel aggregates: a Selection Model a View a Store Scrollers Ext.grid.header.Container TablePanelDirectEvents| TablePanelListeners| TableView|This class encapsulates the user interface for a tabular data set. It acts as a centralized manager for controlling the various interface elements of the view. This includes handling events, such as row and cell level based DOM events. It also reacts to events from the underlying Ext.selection.Model to provide visual feedback to the user. This class does not provide ways to manipulate the underlying data of the configured Ext.data.Store. This is the base class for both Ext.grid.View and Ext.tree.View and is not to be used directly. TableViewDirectEvents| TableViewListeners| TabMenu| TabPanel| TabPanelDirectEvents| TabPanelListeners| Tabs| TabScrollerMenu| TabStrip|A component which renders tabs similar to a TabPanel and can toggle visibility of other items. TabStripDirectEvents| TabStripListeners| Tag| TagColumn| TagField| TagLabel| TagLabelBase| TagLabelDirectEvents| TagLabelListeners| Tags| Task| TaskCollection| TaskDirectEvents| TaskListeners| TaskManager| TBarCollectionBuilder<TParent, TParentBuilder>| TemplateColumn| TextArea| TextBoxConverter| TextField| TextFieldBase| TextFieldDirectEvents| TextFieldListeners| ThreeStateBoolJsonConverter| TimeAxis|A type of axis whose units are measured in time values. Use this axis for listing dates that you will want to group or dynamically change. If you just want to display dates as categories then use the Category class for axis instead. TimeField| TimePicker|A time picker which provides a list of times from which to choose. This is used by the Ext.form.field.Time class to allow browsing and selection of valid times, but could also be used with other components. By default, all times starting at midnight and incrementing every 15 minutes will be presented. This list of available times can be controlled using the minValue, maxValue, and increment configuration properties. The format of the times presented in the list can be customized with the format config. To handle when the user selects a time from the list, you can subscribe to the selectionchange event. Tip|This is the base class for Ext.tip.QuickTip and Ext.tip.ToolTip that provides the basic layout and positioning that all tip-based classes require. This class can be used directly for simple, statically-positioned tips that are displayed programmatically, or it can be extended to provide custom tip implementations. TokenJsonConverter| TokenSettings| TokenUtils| ToLowerCamelCase| Tool| Toolbar| ToolbarBase| ToolbarCollection| ToolbarCollectionEditor| ToolbarDirectEvents| ToolbarDroppable|Plugin which allows items to be dropped onto a toolbar and be turned into new Toolbar items. To use the plugin, you just need to provide a createItem implementation that takes the drop data as an argument and returns an object that can be placed onto the toolbar. ToolbarDroppableDirectEvents| ToolbarDroppableListeners| ToolbarFill| ToolbarItem| ToolbarItemCreateEventArgs| ToolbarListeners| ToolbarSeparator| ToolbarSpacer| ToolbarTextItem| ToolDirectEvents| ToolListeners| ToolsCollection| ToolsCollectionBuilder<TParent, TParentBuilder>| ToolTip|ToolTip is a Ext.tip.Tip implementation that handles the common case of displaying a tooltip when hovering over a certain element or elements on the page. It allows fine-grained control over the tooltip's alignment relative to the target element or mouse, and the timing of when it is automatically shown and hidden. This implementation does not have a built-in method of automatically populating the tooltip's text based on the target element; you must either configure a fixed html value for each ToolTip instance, or implement custom logic (e.g. in a beforeshow event listener) to generate the appropriate tooltip content on the fly. See Ext.tip.QuickTip for a more convenient way of automatically populating and configuring a tooltip based on specific DOM attributes of each target element. Delegation In addition to attaching a ToolTip to a single element, you can also use delegation to attach one ToolTip to many elements under a common parent. This is more efficient than creating many ToolTip instances. To do this, point the target config to a common ancestor of all the elements, and then set the delegate config to a CSS selector that will select all the appropriate sub-elements. When using delegation, it is likely that you will want to programmatically change the content of the ToolTip based on each delegate element; you can do this by implementing a custom listener for the beforeshow event. Alignment The following configuration properties allow control over how the ToolTip is aligned relative to the target element and/or mouse pointer: anchor anchorToTarget anchorOffset trackMouse mouseOffset Showing/Hiding The following configuration properties allow control over how and when the ToolTip is automatically shown and hidden: autoHide showDelay hideDelay dismissDelay ToolTipBase|ToolTip is a Ext.tip.Tip implementation that handles the common case of displaying a tooltip when hovering over a certain element or elements on the page. It allows fine-grained control over the tooltip's alignment relative to the target element or mouse, and the timing of when it is automatically shown and hidden. This implementation does not have a built-in method of automatically populating the tooltip's text based on the target element; you must either configure a fixed html value for each ToolTip instance, or implement custom logic (e.g. in a beforeshow event listener) to generate the appropriate tooltip content on the fly. See Ext.tip.QuickTip for a more convenient way of automatically populating and configuring a tooltip based on specific DOM attributes of each target element. Delegation In addition to attaching a ToolTip to a single element, you can also use delegation to attach one ToolTip to many elements under a common parent. This is more efficient than creating many ToolTip instances. To do this, point the target config to a common ancestor of all the elements, and then set the delegate config to a CSS selector that will select all the appropriate sub-elements. When using delegation, it is likely that you will want to programmatically change the content of the ToolTip based on each delegate element; you can do this by implementing a custom listener for the beforeshow event. Alignment The following configuration properties allow control over how the ToolTip is aligned relative to the target element and/or mouse pointer: anchor anchorToTarget anchorOffset trackMouse mouseOffset Showing/Hiding The following configuration properties allow control over how and when the ToolTip is automatically shown and hidden: autoHide showDelay hideDelay dismissDelay TransformGrid| TranslateAttribute| TrayClock| TreeColumn|Provides indentation and folder structure markup for a Tree taking into account depth and position within the tree hierarchy. TreeDragZone| TreeDropZone| TreeNodeDirectEvents| TreeNodeListeners| TreePanel| TreePanelBase| TreePanelDirectEvents| TreePanelListeners| TreeSelectionModel|Adds custom behavior for left/right keyboard navigation for use with a tree. Depends on the view having an expand and collapse method which accepts a record. TreeStore|The TreeStore is a store implementation that is backed by by an Ext.data.Tree. It provides convenience methods for loading nodes, as well as the ability to use the hierarchical tree structure combined with a store. This class is generally used in conjunction with Ext.tree.Panel. This class also relays many events from the Tree for convenience. Using Models If no Model is specified, an implicit model will be created that implements Ext.data.NodeInterface. The standard Tree fields will also be copied onto the Model for maintaining their state. Reading Nested Data For the tree to read nested data, the Ext.data.reader.Reader must be configured with a root property, so the reader can find nested data for each node. If a root is not specified, it will default to 'children'. TreeStoreBase| TreeStoreDirectEvents| TreeStoreListeners| TreeSubmitConfig| TreeView| TreeViewDragDrop|This plugin provides drag and/or drop functionality for a TreeView. It creates a specialized instance of DragZone which knows how to drag out of a TreeView and loads the data object which is passed to a cooperating DragZone's methods with the following properties: copy : Boolean The value of the TreeView's copy property, or true if the TreeView was configured with allowCopy: true and the control key was pressed when the drag operation was begun. view : TreeView The source TreeView from which the drag originated. ddel : HtmlElement The drag proxy element which moves with the mouse item : HtmlElement The TreeView node upon which the mousedown event was registered. records : Array An Array of Models representing the selected data being dragged from the source TreeView. It also creates a specialized instance of Ext.dd.DropZone which cooperates with other DropZones which are members of the same ddGroup which processes such data objects. Adding this plugin to a view means that two new events may be fired from the client TreeView, beforedrop and drop. Note that the plugin must be added to the tree view, not to the tree panel. TriggerEventArgs| TriggerField| TriggerFieldBase| TriggerFieldDirectEvents| TriggerFieldListeners| TypeUtils| UnitJsonConverter| UpdateOptions| UserControlAddedEventArgs| UserControlLoader| UserControlRenderer| UserControlRendererConfig| UuidIdGenerator|This class generates UUID's according to RFC 4122. This class has a default id property. This means that a single instance is shared unless the id property is overridden. See http://www.ietf.org/rfc/rfc4122.txt for details. ValidationCollection| ValidationStatus| VBoxLayoutConfig|A layout that arranges items vertically down a Container. This layout optionally divides available vertical space between child items containing a numeric flex configuration. This layout may also be used to set the widths of child items by configuring it with the align option. VerticalMarker| VerticalMarkerDirectEvents| VerticalMarkerListeners| ViewCollection<T>| ViewItem| ViewItemCollection| Viewport| ViewportBase| WaitConfig| WebConfigUtils| WebStorageProxy|WebStorageProxy is simply a superclass for the localStorage and sessionStorage proxies. It uses the new HTML5 key/value client-side storage objects to save model instances for offline use. Proxy throws an client side error if local storage is not supported in the current browser WeekView|Displays a calendar view by week. This class does not usually need to be used directly as you can use a CalendarPanel to manage multiple calendar views at once including the week view. Window| WindowCollection| WindowDirectEvents| WindowListeners| WindowManager|The default global floating Component group that is available automatically. This manages instances of floating Components which were rendered programatically without being added to a Container, and for floating Components which were added into non-floating Containers. Floating Containers create their own instance of ZIndexManager, and floating Components added at any depth below there are managed by that ZIndexManager. WriterCollection| X|Ext core utilities and functions. XController|Controllers are the glue that binds an application together. All they really do is listen for events (usually from views) and take some action. Here's how we might create a Controller to manage Users: Ext.define('MyApp.controller.Users', { extend: 'Ext.app.Controller', init: function() { console.log('Initialized Users! This happens before ' + 'the Application launch() function is called'); } }); The init function is a special method that is called when your application boots. It is called before the Application's launch function is executed so gives a hook point to run any code before your Viewport is created. The init function is a great place to set up how your controller interacts with the view, and is usually used in conjunction with another Controller function - control. The control function makes it easy to listen to events on your view classes and take some action with a handler function. Let's update our Users controller to tell us when the panel is rendered: Ext.define('MyApp.controller.Users', { extend: 'Ext.app.Controller', init: function() { this.control({ 'viewport > panel': { render: this.onPanelRendered } }); }, onPanelRendered: function() { console.log('The panel was rendered'); } }); We've updated the init function to use control method to set up listeners on views in our application. The control method uses the ComponentQuery engine to quickly and easily get references to components on the page. If you are not familiar with ComponentQuery yet, be sure to check out the documentation. In brief though, it allows us to pass a CSS-like selector that will find every matching component on the page. In our init function above we supplied 'viewport > panel', which translates to "find me every Panel that is a direct child of a Viewport". We then supplied an object that maps event names (just 'render' in this case) to handler functions. The overall effect is that whenever any component that matches our selector fires a 'render' event, our onPanelRendered function is called. Event domains In Ext JS 4.2, we introduced the concept of event domains. In terms of MVC, an event domain is one or more base classes that fire events to which a Controller wants to listen. Besides Component event domain that encompass Ext.Component-descended Views, Controllers now can listen to events from data Stores, Ext.Direct Providers, other Controllers, and Ext.globalEvents. This feature provides a way to communicate between parts of the whole application without the need to bind controllers together tightly, and allows to develop and test application parts in isolation. See usage examples in listen method documentation. Using refs One of the most useful parts of Controllers is the ref system. These use the Ext.ComponentQuery to make it really easy to get references to Views on your page. Let's look at an example of this now: Ext.define('MyApp.controller.Users', { extend: 'Ext.app.Controller', refs: [{ ref: 'list', selector: 'grid' }], init: function() { this.control({ 'button': { click: this.refreshGrid } }); }, refreshGrid: function() { this.getList().store.load(); } }); This example assumes the existence of a Grid on the page, which contains a single button to refresh the Grid when clicked. In our refs array, we set up a reference to the grid. There are two parts to this - the 'selector', which is a ComponentQuery selector which finds any grid on the page and assigns it to the reference 'list'. By giving the reference a name, we get a number of things for free. The first is the getList function that we use in the refreshGrid method above. This is generated automatically by the Controller based on the name of our ref, which was capitalized and prepended with get to go from 'list' to 'getList'. The way this works is that the first time getList is called by your code, the ComponentQuery selector is run and the first component that matches the selector ('grid' in this case) will be returned. All future calls to getList will use a cached reference to that grid. Usually it is advised to use a specific ComponentQuery selector that will only match a single View in your application (in the case above our selector will match any grid on the page). Bringing it all together, our init function is called when the application boots, at which time we call this.control to listen to any click on a button and call our refreshGrid function (again, this will match any button on the page so we advise a more specific selector than just 'button', but have left it this way for simplicity). When the button is clicked we use out getList function to refresh the grid. You can create any number of refs and control any number of components this way, simply adding more functions to your Controller as you go. For an example of real-world usage of Controllers see the Feed Viewer example in the examples/app/feed-viewer folder in the SDK download. Generated getter methods Refs aren't the only thing that generate convenient getter methods. Controllers often have to deal with Models and Stores so the framework offers a couple of easy ways to get access to those too. Let's look at another example: Ext.define('MyApp.controller.Users', { extend: 'Ext.app.Controller', models: ['User'], stores: ['AllUsers', 'AdminUsers'], init: function() { var User, allUsers, ed; User = this.getUserModel(); allUsers = this.getAllUsersStore(); ed = new User({ name: 'Ed' }); allUsers.add(ed); } }); By specifying Models and Stores that the Controller cares about, it again dynamically loads them from the appropriate locations (app/model/User.js, app/store/AllUsers.js and app/store/AdminUsers.js in this case) and creates getter functions for them all. The example above will create a new User model instance and add it to the AllUsers Store. Of course, you could do anything in this function but in this case we just did something simple to demonstrate the functionality. XControllerBase| XmlReader| XmlWriter|Writer that outputs model data in XML format XScript| XTemplate|

Structures

Name|Description -|- ClientIDMode| ItemSelectorButton| MultiUploadButtonAction| PropertyGridEditorType| RemoteTreeAction| ResourceType| SummaryDock|

Interfaces

Name|Description -|- IAjaxPostBackEventHandler| IAlias| IApply| IAutoPostBack| IBase| IClientConfig| IContent| IControlBuilder| IControlBuilder<T>| ICustomConfigSerialization| IDate| IDependencyItems| IDynamicUserControl| IField| IIcon| IItems| ILayout| ILazy|Marker interface: class can be lazy instantiated ILazyItems| INoneContentable| INoneEditable| IProxyContainer| IQuotable| IResourceManager| IScriptable| IScriptBuilder| IScriptBuilderConfig| ISelfRenderingPage| IStore<T>| IToolbarItem| IVirtual| IXControlBuilder<T>| IXObject| IXPostBackDataHandler|

Enums

Name|Description -|- AjaxRequestType| Alignment| AnchorPoint| AnimationType| ApplyMode| ArrowAlign| AutoGeneratingScript| BatchUpdateMode|Updating behavior based on batch synchronization BoxLabelAlign|The position relative to the checkbox/radio where the boxLabel should appear. BoxPack|Controls how the child items of the container are packed together. ButtonScale|The size of the Button ButtonsShowMode| ButtonTextAlign|The text alignment for a button (center, left, right). ButtonType| ChartExportType| ChartMask| ClientProxy| ClientTarget| CloseAction| CollapseMode| CollapseTarget|Relative position of the immediate sibling Panel to collapse Comparison| ConfigOptionsExtraction| CssPosition| DataLoadMode| DatePickerType| DateUnit| DefaultRenderTo| DesignMode| DirectEventType| Direction| DirectMethodProxyIDMode| Dock| DominantBaseline|CSS3 : The 'dominant-baseline' property is used to determine or re-determine a scaled-baseline-table. DropDownMode| DropPoint|The point of the drop Easing| EditorAutoSizeDimension| EmptyValue|Empty value representation EventAction| FilterType| HBoxAlign|Controls how the child items of the container are aligned HideMode| HtmlEvent| HttpMethod|List of HTTP methods (verbs), RFC 2616 Icon| IconAlign| IDMode| ImageLocationType| InitScriptMode| InitValueValidation|Defines behaviour of field remote validation for init value InputType| InsertPosition| JsonMode| KeyCode| LabelAlign| LayoutType| LazyMode| LegendPosition| LoadMode|The type of content that is to be loaded into a component, which can be one of 4 types MaskTarget| MessageTarget| ModelFieldType|The data type for conversion to displayable value MultiSelectMode| NoteAlign| Orientation| Overflow| ParameterMode| PasswordMaskMode| PickerAutoPostBackEvent| Position| Region| RendererFormat|Reusable data formatting functions RenderMode| ResizeHandle| ResourceLocationType| ResourceMode|An enumeration of possible modes for ResourcePlaceHodler. ScriptMode| ScriptPosition| ScrollMode| SelectionMode|Selection mode for selection model SelectionType| SeriesLabelDisplay|Specifies the presence and position of labels for each pie slice. ShadowMode|The shadow display mode. ShowMode| ShrinkWrap|In CSS terms, shrink-wrap width is analogous to an inline-block element as opposed to a block-level element. Some container layouts always shrink-wrap their children, effectively ignoring this property (e.g., Ext.layout.container.HBox, Ext.layout.container.VBox, Ext.layout.component.Dock). SortDirection| SortTypeMethod|Sort types SpriteType|The type of the sprite. StandardChartTheme| StateProvider| StatusAlign| StoreAction| StrokeLinecap| StrokeLinejoin| SummaryType| TabAlign| TabPosition| TagSelectionMode|Selection mode for tag label TemplateWriteMode|The Ext.XTemplate method to use when updating the content area of the AbstractComponent TextAlign|The text-align property specifies the horizontal alignment of text in an element. Theme| ThreeStateBool| TimeIntervalUnit| TitleAlign| ToolTipType| ToolType| TreePanelMode| TriggerAction| TriggerIcon| ValidationEventOwner| ValidationType|Standard validation types VBoxAlign|Controls how the child items of the container are aligned. ViewStateMode| VisibilityMode|