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.) librariesExactly. 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 Ajax.PeriodicUpdater.
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 ?
i.e.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 'cocoon-ajax'
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 JeremyPS. 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">.
smime.p7s
Description: S/MIME cryptographic signature
