Posted by OliverColeman on October 20, 2011 at 3:07am
| Download | Size | md5 hash |
|---|---|---|
| ext-6.x-2.x-dev.tar.gz | 52.67 KB | 46cdd656be25b302c4628a0d1a86d9e9 |
| ext-6.x-2.x-dev.zip | 63.27 KB | 04c1adcb7fd56b2d4ceb832d6332267f |
Last packaged version: 6.x-2.x-dev
Last updated: March 15, 2012 - 12:14
Release notes
This is a dev release of a completely new version of the ext module for Ext JS 4.0. While this code probably provides some useful functionality, it is in a pre-alpha state and is likely to change substantially over the next few months. The README.txt file provides a thorough description of the APIs this module currently offers.
The current implementation provides:
- Loading of the Ext library and some basic settings.
- A hook-based API to allow other modules to specify Ext Model and Store definitions and code to support CRUD operations on them (although for Stores only the Retrieve operation is supported at the moment). There is also support for defining access/permission functions, and half the code required to allow server-side validation for Models (this isn't supported out of the box by Ext). Using the definitions JS files are generated that create the Model and Store classes in Ext on the client. The README.txt file details this API.
- A RESTful API for CRUD operations on Models and Retrieve operations on Stores. The Model and Store definitions in the generated JS files are automatically augmented with the appropriate Proxy definitions to communicate with the REST interface.
- Model definitions for nodes (a generic one for all nodes, and one for each content type that includes CCK fields) and users (including profile fields), and the supporting code for full CRUD operations on them via the REST interface. There is the beginnings of code to create Model definitions for comments, terms and files; using the existing code as an example it wouldn't take much to implement these. The node and user Model definitions automatically detect and generate definitions for relationships (known as associations in Ext) to other nodes and users (including via the CCK nodereference field), as well as most validations from standard node and user fields as well as CCK and profile fields (the code to handle server-side validation for PHP-generated "allowed values" lists for CCK fields is not yet implemented). The associations code is not yet complete (I think in the latest version of the code the primaryKey and foreignKey are the wrong way around, and loading Model data in nested format is not yet supported; this is what I'm currently working on).
- Store definitions for Views (for each Views display). Additionally Models are generated for each View display that uses fields, however at the moment it is not possible to save instances of these Models (there is the beginnings of code for this, but it will require extracting the save-able data from the field names that Views generates in its result objects).
- A unified Model and Store administration UI with an API to allow modules to customise the edit/add form for user-created Model definition types.
- A module that uses the above APIs to allow an admin to define Models and Stores to be used as Tree nodes and TreeStores respectively (allows choosing the association to use for the child/parent relationship, the root node of the tree store, etc). This is mostly implemented.
ToDo
The below is likely to change (note the question marks).
- Use Services module instead of own REST implementation?
- Layout and integrating Drupal page elements and Ext components (requirements, implementation suggestions):
- Provide useful off-the-shelf functionality for non-developers?
- Allow rendering some elements using Ext: menus, grids from defined stores, trees from defined model relationships, ?
- Override/create theme functions for these.
- Allow flexibility in layout for developers.
- Allow dev to define layout in Ext code?
- Create API to allow defining Ext “xtypes”.
- Provide RPC API to retrieve content from server/Drupal.
- Create plug-in to provide xtypes for various types of content (eg block, menu, main page content), with config option to specify ID for content (eg block ID, menu name, page address).
- Avoid use of iframes.
- Create reset stylesheet against Drupal core CSS to make it compatabile with Ext CSS, create base Ext theme (ala Zen theme).
- Allow specifying if links/buttons in Drupal content should be modified to prevent reloading the site, ie create AJAX request using link address or form submission and replace xtype panel content (either the panel containing the link or some other panel) with result.