cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: RFC: Ajax Roadmap
Date Fri, 09 Dec 2005 14:43:29 GMT

On 9 Dec 2005, at 12:46, hepabolu wrote:

> Jeremy Quinn wrote:
>
>> I am working on refactoring our CForms Ajax code to use the Dojo  
>> Ajax  Library. [1]
>
> GREAT!
>>

:)

>> 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.
>
> +1, will this be available in the 2.1 branch as well or will it be  
> reserved for 2.2?

I understood that the Forms Block was shared between the two branches.
I am working in 2.1.

>
>> 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 :)
>
> Great, this has been on my wish list for quite some time.

I just hope the Safari problems can be overcome, plus this is not  
tested at all on Windows yet ;)

>
>> 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.
>
> +1
>
>> 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.
>
> +1
>
> Are they mutually exclusive?

There is a bunch of code to support the background updating of  
widgets (without page refresh) like adding to or rearranging items in  
a repeater widget, that is not needed if Ajax is not turned on for  
the form.

> There was a thread lately by Antonio about resetting the form/ 
> widget handlers to null, thereby removing the ability for widgets  
> to use AJAX after the first (AJAX) submit. For non-ajax forms that  
> was the correct behaviour IIUC.

Yes I read that.
I am not completely up to speed on the issues, but would expect to re- 
visit that when dealing with the events stuff (below).

>> 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.
>
> +1
>
>> DOMUtils from cocoon-ajax.js either get incorporated into   
>> cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils.
>
> what would be the reason to make it separate?

I don't have any strong arguments either way ATM.

>> Re-implement our BrowserUpdater(s) using dojo.io.bind. [3]
>> Re-implement our load and submit event handlers using   
>> dojo.event.connect. [4]
>
> I cannot figure out the implications for this, but given the goal  
> of minimizing our own ajax code: +1
>
>> Determine which existing CForms code/widgets etc. may be replaced  
>> by  their dojo equivalent.

This could include stuff like tabs, help popups, visual effects,  
trees, date picker, rich text editor etc.

>> Determine which existing CForms code/widgets etc. do not have a  
>> dojo  equivalent and what to do about it.

I am not sure there is a dojo equivalent to our multivalue fields, we  
may prefer the functionality of our current date picker, rich text  
editor etc.

>> Determine what widgets there are in dojo, that are not in CForms  
>> but  may be usefully added to CForms.

There are widgets for time picking, colour picking, etc.

> This I don't understand (due to lack of dojo knowledge). Could you  
> give one example of each?

I also probably do not have enough knowledge yet about available dojo  
widgets either, yet :)

But see above.

> IIUC Dojo is all client-side behaviour of widgets. There is nothing  
> that could replace the server-side, model and binding of CForms. If  
> all this is true, I don't understand the above 3 actions.

Some of the behaviours we have in Ajax CForms are purely client-side  
code, others a mixture of client and server-side. Dojo helps with the  
client-side in terms of its widget framework but also with stuff like  
the interaction between client and server, it's powerful event api etc.

CForms would continue to work in the same way, i.e. transparently  
provide the behaviours you turn on in your form. Hopefully the range  
of behaviours can get richer, while the amount of code for us to  
maintain gets smaller :)

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

Thanks for your response.

regards Jeremy


Mime
View raw message