cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: RFC: Ajax Roadmap
Date Fri, 09 Dec 2005 17:17:00 GMT
Jeremy Quinn wrote:

> Hi All
>
>
> I am working on refactoring our CForms Ajax code to use the Dojo Ajax  
> Library. [1]
>
> The aim of this is to reduce the amount of cocoon-specific ajax code  
> that needs maintaining by us, to a minimum, while simultaneously  
> adding useful new functionality.
>
> The first thing I have done is to use the dojo.require mechanism to  
> dynamically load all JS in the browser, so for instance, if your form  
> does not use htmlarea, the javascripts are not loaded :)
>
> This goes for all of the cforms, ajax, mattkruse and htmlarea libs we  
> currently use.
>
> This is not working in Safari ATM, so I cannot commit the changes yet  
> unfortunately. I am pretty confidant that it is fixable. [2]
>
> So what is the next step?
>
> This is what I was thinking, I would appreciate your feedback.
>
> Refactor Cocoon JS
> ------------------
>
> forms-lib.js and cforms.js get merged into a new file that will  
> contain all (non-ajax) CForms-specific code in the following  
> namespace: cocoon.forms.cforms.

Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"?

>
> Any ajax-specific code from the files above and from cocoon-ajax.js  
> go into a new file in the following namespace:  cocoon.ajax.cforms.  
> This is only loaded by your browser if you have Ajax enabled in your  
> form.

cocoon.ajax.cforms --> cocoon.ajax.forms

3 levels are ok if we will have others "cocoon.ajax.????" namespaces, if 
not the case, then "cocoon.ajax" should be enough.

Shorter names --> faster typing --> faster development. ;-)

>
> FormsMultiValueEditor from forms-lib.js goes into it's own file in  
> the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be  
> loaded only when that widget is displayed.

AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is 
true, then we should not store it under "cocoon.ajax"?
Here is something interesting, JS allow us to create more complex 
widgets. The FormsMultiValueEditor is only one of this "complex" 
widgets. I believe in the future we can have more sofisticated widgets 
as a widget looking up data from a database and others. If this is 
really going to happens, then we can create a namespace for them:

cocoon.ajax.widget
cocoon.forms.widget

Hence we can store the FormsMultiValueEditor under:

cocoon.forms.widget.FormsMultiValueEditor

WDYT?

>
> DOMUtils from cocoon-ajax.js either get incorporated into  
> cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils.

+1 for cocoon.ajax.DOMUtils

>
> Switch to Dojo Libs
> -------------------
>
> Re-implement our BrowserUpdater(s) using dojo.io.bind. [3]
>
> Re-implement our load and submit event handlers using  
> dojo.event.connect. [4]
>
> Determine which existing CForms code/widgets etc. may be replaced by  
> their dojo equivalent.
>
> Determine which existing CForms code/widgets etc. do not have a dojo  
> equivalent and what to do about it.
>
> Determine what widgets there are in dojo, that are not in CForms but  
> may be usefully added to CForms.
>
> Determine what widget functionality is available in dojo, but not in  
> CForms that could be added to our widgets (drag and drop repeaters?  
> upload progress bar ? etc.).

+1!

Thanks Jeremy for taking care of this. :-)

Best Regards,

Antonio Gallardo.


Mime
View raw message