Roadmap for ext 2.0 (supporting Ext 4) [#1316616]

Comment #0.0

OliverColeman commented 21 October 2011 at 04:47

Issue summary:

View changes

Added invitation to leave feedback

Log in or register to post comments

Comment #1

ckng

English

commented 19 December 2011 at 18:08

Not sure how this is best implemented.

But have you consider the possibility of using Ext.Direct
or Views + Views Datasource?

Log in or register to post comments

Comment #2

OliverColeman commented 16 February 2012 at 05:15

Thanks for suggestion ckng. Views Datasource looks interesting, however unfortunately I don't think it will be of much use for this rewrite. The rewritten ext module does use Views as a data source for Ext Stores and Models (depending on the row style plugins used for each View), but most of the code for doing this has already been written and isn't particularly substantial (so the Views Datasource module looks like it would be overkill even if it does provide a useful API for dealing with Views data).

Log in or register to post comments

Comment #3

OliverColeman commented 16 February 2012 at 06:02

The MVC portion of the rewrite is nearing completion, the following has been implemented and tested, and the APIs are now pretty stable:

Loading of the Ext library.
Automatic generation of JS code for Ext Model and Store definitions.
An API to allow modules to specify Ext Model and Store definitions, and alter definitions provided by other modules.
Provides Model definitions for the following Drupal objects: node (one for each content type, including CCK fields), comment, user, ~~term~~ and file. Provide the supporting code for full CRUD operations on them via the REST interface.
Provides Store definitions for Views (for each Views display). Additionally generate Model definitions for each View display that uses fields.
An API to allow setting various Ext application-wide settings and configurations.
An API to allow including custom Ext classes via the Ext dynamic class loading functionality.
A RESTful API for CRUD operations on Models and Retrieve operations on Stores (the generated Model and Store definitions are set-up to use this API by default)
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.
API to assist with storing Model and Store configurations, primarily to allow exporting via the Features module.
Provide module to allow an admin to define Models and Stores to be used as Tree nodes and TreeStores respectively.

I think this should be very useful for anyone implementing an Ext UI with a Drupal backend. This module is being developed to power a fairly complex application and has proven to be very useful. Give it a go!

Note that Ext 4.1.x is required.

The hook API can be viewed here: http://drupalcode.org/project/ext.git/blob_plain/refs/heads/6.x-2.x:/ext...

The other proposed parts of the rewritten module, an API to enable including Drupal page elements and content in Ext, will be started on soon...

I'm not so sure when the API to enable including Ext components in Drupal content will be started on as we probably won't be using this for the project this module is being developed for, but ironically it should be one of the easier parts to implement (shout out if you want to help ;)).

Log in or register to post comments

Comment #4

hestros commented 22 February 2012 at 14:22

There seams that Views 3 (D7) draws a clear path of integration ExtJS with drupal.
Views can be used as models (data) or configurable Layouts, parsing fields and expose formatted json (picked up by page's url) and as templates with fine tuning outputs (styling ctr).
There could be written an initial module for the basic requirements of the library (extjs) and maybe some generic views (code views) for application structure or module structure. Application views for example would have two handler, model and view (equivalent to MVC structure of ExtJS) and plugins to serve as Controllers.
Then it could be possible for users (web masters) to create their views based on fields of core entities or customized witch Views 3 has became quite efficient to handle.
Then other modules that hooked on the initial module will produce more extensions (like those in the samples folder in extjs 4). No need for extra logic accept maybe entity_info if that is vital.
The path is there and I can hear already the fuzz. All we have to do is take it. :)
This is not a road map rather a rough idea, but in my opinion is the most "drupal" way to ExtJS I can see right now.
I don't have any code to suggest right now as I have to comprehend overall the way Views is build (and execute and display) rather to replicate existing (third party modules or native views 3 ) views, handlers and plugins, 'cause my guess is that the plugins must be very carefully designed to serve their purpose and right now most of them are loaded with many unnecessary data (very fat arrays). And since views 3 has no documentation, studding previous version docs it sound redundant, as best is to study the actual code.
Maybe someone with compound understanding of CTools can suggest a non views approach, but it is likely to end up on the same point as we have to invent fields handling.
Any thoughts?

Log in or register to post comments

Comment #5

OliverColeman commented 22 February 2012 at 21:03

I haven't looked at Drupal 7 and Views 3 at all (would love to, but projects I've been working on have been stuck at D6 for various reasons and I haven't had any spare time!). It sounds like the implied suggestion is that because in D7 (almost) everything is built from fieldable entities, and Views 3 can handle retrieval and display of any fieldable entity (correct me if I'm wrong), we can use it as the main engine behind an ext integration module, at least for Ext JS Models and Stores, and perhaps also in a more direct way to determine what fields get rendered (and perhaps how they're rendered) in some Ext JS Views (eg Ext JS Grids and Charts). Assuming this is correct, this does sound like a good idea. :) In any case, Drupal 7 should make the Models and Stores aspect of integration a lot easier with its uniform Fields API.