-- Deanna Bonds <deanna.bo...@adelphia.net> wrote (on Tuesday, 03 March 2009, 06:30 PM -0600): > I had started this concept a while ago but never had time. I want to > create a zend framework class set for ExtJS. I will use the model of > dojo as far as it applies, but it and extjs have different scopes. dojo > is more of a way to make your pages dynamic and ajaxie, extjs is more > of an web application framework.
I'd argue that point, but don't want to start a flame war... > In ExtJS you don't have to have any html elements at all in your > page, you create them all with javascript components. ExtJS lends > itself to the load the page once and everything else is done by js > and ajax. Dojo as well. > So what is needed is a Zend_ExtJS_Controller_Action class that uses > the ajaxcontext on all the action methods in the class and will by > default throw a 403 error if accessed from the browser URL and not an > xhr request. A better way would be to do this via a helper extending Zend_Controller_Action_Helper_AjaxContext. In that helper's init() method, have it grab the current action controller, scan it for the various methods ending in 'Action', and add the ajax context to each. Then register that helper in the _bootstrap_ so that it triggers for every controller. Let me know if you need some help with the code for this. > There will be a debug mode but more on that later. > So the default action will be to send all the view vars by json (per the > ajaxcontext). There will be view helpers to help create the proper > formatted ajax calls. send_success(optional data); > send_failure(optional message); > send_form_errors(either Zend_ExtJS_Form object or array of associated > errors, data array of associated data); > send_form_data(data) data for the form to load. > send_store(Zend_ExtJS_Store); > send_component(name, ExtJS_Component decedent);sends back a config > object with xtypes Why not have these as a single helper with multiple methods? That's how the Dojo and JQuery helpers work -- and it keeps the functionality grouped nicely. Additionally, use camelCasing instead of under_scoring to keep with ZF conventions. > For forms and other components extjs takes a json config object with an > xtype for lazy instantiation of the object. I will write a helper js > function on the js side that will take the ajax return and get the > component by name. You might be able to do this as special form decorators as well. > Some config objects need handlers defined in them. > To facilitate this, create a Zend_ExtJS_Handler object that takes > javascript code to be applied to the config object. The code and a map > where to apply the eval'ed code (actuall new Function(code)) will be > generated. This is somewhat similar to how the Dojo integration works, actually, thouh we don't require a "handler" object -- instead, we just send a plain old JS object back that Dojo then consumes. > Also components may need to reference data stores, > Zend_ExtJS_Store, (such as drop down lists), so we will do a similar > map with them. So sending components back will be an array like this > > array( 'comp1Name' => array ( 'config' => json config object, 'handlers' > => array( handlers ), 'stores' => array(...)), > 'comp2Name' .... This sounds similar to dojo.data; do you know if there is any overlap? You may want to look at Zend_Dojo_Data for some techniques on accomplishing this. > For the component and its decedents calls, There will be something > similar to the Dojo form set with elements, but the extjs version, plus > some other extjs components such as panel, window, grid, tabpanel. The dojo integration targets most layout dijits as well, which includes items similar to what you name above. > If there is something not defined it should be able to be created by > using the Zend_ExtJS_Component class and defining xtype and > parameters manually. > > the Zend_ExtJS class will work basically like the dojo version. You > point it to your local extjs folder and it will create the includes for > you. If you are in debug mode it will use the debug version of the js > library if not then the minified version. Also on the debug, if you > are in debug mode, instead of the controller throwing a 403 error when > accessed by a browser, IF you also add the parameter extjs-mode=dump, > it will do a var dump of the view vars. If instead you add extjs-mode > test, it will create the js code to make and show any components you > have sent. If you don't include any extjs-mode param it will throw the > 403 error still. > > I don't see any use for the other view helpers that will let you create > extjs in your view piecemeal, extjs code is never a part of the html > markup. > > Do the Zend guys approve the overall concept and have suggestions to > make it more zend like? I know I will still have to do the use cases > and write up, but want to make sure on the basic right path first. The ideas sound pretty good. I have a few concerns, however. First, this would have to live in the ZendX namespace, not Zend. Internally, we can only support one JS toolkit, and the toolkit we have chosen is Dojo. Integration with other toolkits is allowed and encouraged -- but must be completely community supported and live in the ZendX namespace. That's currently where the jQuery integration lives, and I've had good communication channels with the author of that integration. Now, my second and bigger concern has to do with licensing. One reason we did not consider Extjs when looking at JS libraries to integrate is due to licensing. In point of fact, Extjs' licensing model is incredibly viral, and makes it difficult to build sites with it unless you _purchase_ a commercial license. I actually think we'd need to bring in our lawyers before we could include integration with Extjs even in ZendX (which is where this integration would need to live) as there are clauses in the Extjs license that make it appear that even distributing code that _integrates_ with Extjs invokes their license. I advise to you go ahead and proceed with creating a proposal, and if/when it gets to the point that it's ready for recommendation, we can revisit the licensing issues. -- Matthew Weier O'Phinney Software Architect | matt...@zend.com Zend Framework | http://framework.zend.com/
