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 <[email protected]> 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
