cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: New Ajax block, CForms autocompletion suggestion-lists
Date Fri, 30 Sep 2005 11:42:13 GMT

On 29 Sep 2005, at 11:26, Sylvain Wallez wrote:

> Jeremy Quinn wrote:
> <snip/>
>> Cool !
>> As you know, I have some code to contribute that uses the same   
>> BrowserUpdate mechanism as you use in CForms. An existing   
>> TimedBrowserUpdater, that periodically updates parts of the page   
>> using a Timer, and (not written yet) LinkedBrowserUpdater, which  
>> will  be triggered by a link instead of a timer.
>> Now you have made an AJAX Block, it looks like the right place to  
>> put  it.
>> .... but I do not want to get in your way .... I get the feeling  
>> that  you are in the process of moving from the original ajax  
>> libraries  used by CForms to the Scriptaculous (etc.) libraries
> Exactly. Scriptaculous and Prototype give way more features and are  
> heavily tested in a number of environments and therefore have  
> solved many cross-browser issues. When I wrote the initial Ajax  
> stuff, 2/3 of the time was spent solving such issues and I will be  
> happy to be relieved of them :-)

I completely understand.

>> .... and I do  not want to get in the way by adding libs that you  
>> are moving away from.
>> My stuff uses a slightly adjusted copy of the BrowserUpdater and   
>> (untouched)DOMUtils Objects from cforms.js.
>> Are you planning on moving those to the Ajax block? Are you  
>> planning  on replacing them with code from the new libraries?
> My impression is that Scriptaculous (or the underlying Prototype)  
> provides a similar service. Would you please have a look at  
> Ajax.PeriodicUpdater [1] and tell us how it overlaps with your stuff?

Thanks for the pointer, this lib looks really interesting !

There is /some/ overlap between TimedBrowserUpdater and  

Here are some differences :

1. Because TimedBrowserUpdater uses the same <bu:document> type  
payload in the response as CForms, any number of different elements  
on the page may be updated in one go. AFAIU the current  
implementation of Ajax.PeriodicUpdater, is designed to update one  
element at a time. This will be an issue for CForms as well I guess,  
as currently I believe CForms will send updates for any widgets that  
have a value change.

2. TimedBrowserUpdater and Ajax.PeriodicUpdater have very different  
strategies for dealing with lack of change in the updated content.  
Ajax.PeriodicUpdater has a 'delay' parameter, that makes it begin to  
slow down the frequency of requests, if previous responses have  
contained the same content. TimedBrowserUpdater  always sends  
requests. For each element that it handles, it sends the ID and a  
state value as request parameters, JXMacros on the server compare  
this incoming state value with the current equivalent state on the  
server and only sends the update for this element if there is change.

I would be interested in re-writing TimedBrowserUpdater to use the  
Prototype Libraries if that seemed appropriate.

What I am interested in finding out from you at the moment is how you  
plan to use the Prototype libraries with CForms.

Will the basic mechanism used by Ajax CForms on the Server stay the  
same ?

     Ajax requests come back to the same URL (as the initial page)  
with a 'cocoon-ajax' param
     JXMacros wrap <bu:update id="n"><p>bonjour</p></bu:update>  
according to the state of 'cocoon-ajax'
     The BrowserUpdateTransformer filters according to the state of  
     The Serializer is switched according to the state of 'cocoon-ajax'

Then re-write the existing BrowserUpdate client side JS to use the  
Prototype libraries. In effect providing a generic function that can  
update a page from a <bu:document> that can be given to an  
Ajax.Request Object as the 'onCompleted' handler option.

If this were to be the approach, the new version of  
TimedBrowserUpdater would merely need a slightly extended version of  
the onCompleted handler, as it needs to perform the same update but  
also register any new state values.

Or maybe you are planning to work in a completely different way ?

regards Jeremy

PS. If you plan to stay with the basic BrowserUpdate concept,  
possibly the next useful tag to add to <bu:update> would be  
<bu:insert type="before|top|bottom|after">.

View raw message