Zend_ExtJS

[Deanna Bonds]

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.  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.  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.  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


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.  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.  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' ....

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.  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.

[Vince42]

Hi,

I need to make a very complex database driven form, which retrieves a
rowset and renders that rowset, dependent rowsets, links and applies
various decorators to each element or group of elements.

Currently I am solving this with a Zend_Form extension that iteratively
crawls through all the data, finds dependent rowsets and renders the
results through database-aware Zend_Form_Element extensions appropriately.

As I am currently refactoring that form and the complexity of
configuring and rendering all elements is high, I just wanted to know
whether there is maybe a more sophisticated way to realize such a need.

Any help is highly appreciated. :)

--
Cheers,                        \\|//
Vince                          (o o)
----------------------------ooO-(_)-Ooo-------------------------
 '''   (o)_(o)                                        [ ][0][ ]
 ô¿ô   (=°o°=)   World Domination by Copy and Paste   [ ][ ][0]
  -    (")_(")                                        [0][0][0]

 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachments
                                   Ooo.
---------------------------.ooO----(  )-------------------------
                           (  )    (_/
                            \_)

[weierophinney]

-- Deanna Bonds <[hidden email]> 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       | [hidden email]
Zend Framework           | http://framework.zend.com/

[Deanna Bonds]

Thank you Mathew.  I will make the changes you mentioned.  I am looking
at the dojo integration as a model.  On the licensing issue,  I was
careful to only let zend send back configuration object, not extjs
code.   The helper js routine I write can be distributed separately, as
it isn't required, it just makes things easier client side.  I also am
looking to work with the ExtJS community doing this to make sure I cover
most of the use cases,  I can ask about the licensing there also - just
to be safe.

A few questions about some points

Matthew Weier O'Phinney wrote:

> -- Deanna Bonds <[hidden email]> 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...
>  

Wasn't trying to start any library wars, sorry.  Just was stating what I
thought was the scope of the libraries.  Guess it turns out that thought
was more my opinion, once again sorry.

> 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.
>  
So you are suggesting for every controller that wants to be extjs
controller that it gets the static helper for the extjs that does
initialization.
So I assume Zend_ExtJS init would register the action helper

 From what you described I would guess an init something like
        $controller = $this->getActionController();
       
        $methods = get_class_methods($controller);
        $ajaxContext = $controller->_helper->getHelper('AjaxContext');
        $filter = new Zend_Filter();
        $filter->addFilter(new Zend_Filter_Word_CamelCaseToDash())
            ->addFilter(new Zend_Filter_StringToLower());
        foreach ($methods as $method_name) {
            $pos = stripos($method_name,'Action');
            if($pos){
                $action = substr($method_name,0,$pos);
                $action = $filter->filter($action);
                $ajaxContext->addActionContext($action,
array('json','html'));
            }
        }
        $ajaxContext->initContext();
        Zend_ExtJS::enableView($this->view);

>> 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.
>
>  

So it will be of the form
$this->view->extjs()->sendSuccess();

>> 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.
>  
I will look at that but the output to be converted to json needs to be
something like

array(
                'id' =>  'loginPanel',
                'height' =>  'auto',
                'width' =>  'auto',
                'border' =>  false,
                'bodyBorder' =>  false,
                'baseCls' =>  'x-plain',
                'bodyStyle' =>  'margin:5px;',
                'monitorValid' => true,
                'defaults' =>  array(
                    'validationEvent' =>  'blur',
                    'allowBlank' =>  false,
                    'selectOnFocus' =>  true,
                    'msgTarget' =>  'side',
                    'labelStyle' =>  'font-weight:bold;'
                ),
                'frame' =>  false,
                'labelWidth' => 80,
                'labelAlign' =>  'left',
                'waitMsgTarget' =>  true,

                'items' =>  array(
                    array(
                        'xtype' =>  'textfield',
                        'id' =>  'username-fld',
                        'fieldLabel' =>  'Username',
                        'name' =>  'username',
                        'emptyText' =>  'User ID Required',
                        'autoCreate' => array('autocomplete' => 'on',
'tag' => 'input', 'type' => 'text', 'size' => '20'),
                        'tabIndex' => 1
                    ),array(
                        'xtype' =>  'textfield',
                        'inputType' => 'password',
                        'fieldLabel' =>  'Password',
                        'autoCreate' => array('autocomplete' => 'on',
'tag' => 'input', 'type' => 'password', 'size' => '20'),
                        'name' =>  'password',
                        'tabIndex' => 2
                    ), array(
...

>> 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.
>  

The next version of ff is going to have a json parser, and extjs is
going to use that.  So you can't send js code back and have it evaled
when it is received automatically.  So instead send them back as a
string, with a map where it goes and use new Function() on it.  You have
to use new function if you want anonymous function support,  as pure
eval doesn't like    function() {....};

>  
>> 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.
>
>  

I will reuse as much of that as I can.
>> 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.
>  
That will be the model I use.
> 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.
>  
That is okay if it lives there, as long as it lives :)


Deanna

[Deanna Bonds]

Trying to finish up the design and prototype of the action controller
helper.  The current name is enableAjaxExtJS,  and you can pass it
options in the direct call.  Options are a different context key,  
either a list of methods to enable, or a list of methods to exclude (the
default is to enable context switching on all  *Action methods),  and
option to enable or disable throwing 403 errors if not an xhr request.  
By default I have the 403 errors enabled as that seems to be how I think
most ajax routines.  If you think it should be otherwise I can reverse
that.  Also, I want to be able to enable or disable the throwing of 403
errors on an action by action inside the action method.  If going with
the default as enable as I have it now,  what would the best method name
be to enable it that would make the most sense in zend framework context.

disable403()     That kind of requires the user to realize they aren't
getting normal template processing because of the 403 error.
enableStandardTemplateProcessing()  Very long name
enableViewTemplates()  not quite as clear but shorter

or something else.  If going with 403 errors off by default then I think
enable403() would be be clear enough.

 

[Deanna Bonds]

Another question to go along with the 403 one:  If I use decorators to
create the json config object, then the form can't be used as a normal
html form.  I was thinking along the lines of something like the
decorators but only used in the json context - like jsonDecorators.  So
on the form I would call $form->toJson();   to create the config to send
back as ajax.  But the form could still be used in a normal view as all
forms are.  Does this sound okay?

Deanna Bonds wrote:

> Trying to finish up the design and prototype of the action controller
> helper.  The current name is enableAjaxExtJS,  and you can pass it
> options in the direct call.  Options are a different context key,  
> either a list of methods to enable, or a list of methods to exclude
> (the default is to enable context switching on all  *Action methods),  
> and option to enable or disable throwing 403 errors if not an xhr
> request.   By default I have the 403 errors enabled as that seems to
> be how I think most ajax routines.  If you think it should be
> otherwise I can reverse that.  Also, I want to be able to enable or
> disable the throwing of 403 errors on an action by action inside the
> action method.  If going with the default as enable as I have it now,  
> what would the best method name be to enable it that would make the
> most sense in zend framework context.
>
> disable403()     That kind of requires the user to realize they aren't
> getting normal template processing because of the 403 error.
> enableStandardTemplateProcessing()  Very long name
> enableViewTemplates()  not quite as clear but shorter
>
> or something else.  If going with 403 errors off by default then I
> think enable403() would be be clear enough.
>
>
>