Re: Transparent and automatic AJAX support for CForms
Thought I'd pass on to the Struts list the great success and popularity Frank Zammetti's ideas are having on the Cocoon list. On 4/20/05, Antonio Gallardo [EMAIL PROTECTED] wrote: Hi: Simply, wow, it is great! :-) I started to do something similar 4 days before you posted this solution! My main motivation was because repeater widget with comboboxes are very slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form because the repeater data. The all form was +100kB! Of course, this was an unusable solution. Then we thought that a solution was break the form in more pieces, but this looked very ugly from a user POV. At that time, Tim Larson advised to look for an XmlHttpRequest solution integrated into cforms. The same day, I saw an struts related article in the theserverside: http://theserverside.com/news/thread.tss?thread_id=33056 And I started to migrate this to cocoon in my free time. But with no major success. :-( I think, your solution is more elegant than what I tried to do. My idea was to generate client-side java script for every widget and send it to the browser, then the browser will react to the onfocus event of the widget and fill the list on demand. That way we don't need to fill all the lists at once and the page will load faster. I expected cocoon caching will help here. Also, given the fact that this solution was not needed on every combo, I thought to include an @ajax attribute in the fi namespace on the template as flag. Something similiar like I saw in the struts sample pointed above. Not at the form level as the committed solution. I have 2 questions: 1- Will this ajax implementation improve the combo loads in cforms? 2- Are you planning to merge it in 2.1.x? If not I will see the urge to move to 2.2 soon! :-D Thanks for this great improvement! Best Regards, Antonio Gallardo. On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: Hi all, I've been thinking for a few weeks to add AJAX support to CForms. Ajax is the current buzzword in the blogosphere since Google maps [1] started and the folks at Adaptivepath found this name for the XmlHttpRequest + JS + XML combo [2]. At first this looked like a complex problem, requiring a special controller and special pipelines on the server to answer ajax requests, and ajax-aware implementations of widget styling (i.e. having a JS client-side part to handle page update). Lots of code for the infrastructure, and lots of browser-dependent code each time we want to add a new styling. Then a few days ago I realized that we don't need that complexity. Form widgets have all the information needed to inform the surrounding environment if they need to be updated, and we can use this information to do partial updates of the browser page. Two days hacking, most of which dedicated to writing client-side JS and solving cross-browser compatibility problems and here we are: adding ajax=true on ft:form-template turns on the magic. This is still experimental though: it's only implemented with the JXTemplate version of the CForms template language and requires a few changes on repeater templates. -- oOo -- How does this work? The idea is, when answering and Ajax request, to send back an XML document containing browser updates directives, that will contain document fragments that will replace their existing counterpart in the page, based on the element id. These directives are represented by bu:replace elements (bu = browser update) holding the id of the page element that needs to be replaced. This is a very generic mechanism that at this point isn't specifically related to CForms. This could for example probably be used by the portal to update coplet contents. Now CForms. When a widget is updated in some way (new value, selection list changed, repeater row added or moved, union case updated, etc), it registers itself in a list of updated widgets in the Form object. The template works as usual unless there is a special cocoon-ajax parameter, indicating an ajax request from the browser. In that case, widgets that have changed are enclosed in a bu:replace element, holding the widget id. This mix of template structure, and widget instances surrounded by bu:replace elements goes to styling, which replaces widget instances by their HTML styling, still in the bu:replace elements. A new browser-update transformer flattens the bu:replace elements, i.e it removes all surrounding markup produced by the template. We now have a list of partial page updates that are serialized as XML. On the brower, the update directives are played and the page is updated. And that's all. -- oOo -- Any widget, any styling can now be managed this way. The only -- but important -- constraint is that the html produced for a widget
Re: Transparent and automatic AJAX support for Cocoon Forms
Well, first of all, I was not talking about you. I was talking aboiut Antonio Gallardo and cited his notes on Cocoon. You, no doubt, should be the one I was talking about. And, if I had done what I should have done, I guess, then you would be right to be angry, I think. Reminds me of the old saw I'm not much but I am all I think about. And, second of all, I took attribution and gave attribution for nothing. Reminds me of the old saw Much ado about [absolutely] nothing. You might note that the article referenced is by a gentleman called Frank W. Zammetti. Okay? Take a deep breath. On 4/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Michael McGrady wrote: Thought I'd pass on to the Struts list the great success and popularity Frank Zammetti's ideas are having on the Cocoon list. Ahem... I'm very sorry, but the ajaxification of Cocoon has *nothing* to do with Frank Zametti's ideas. These ideas are *mine* and I *never heard of Frank before*. You should have read the detailed description of my work [1] to understand how different they are from Frank's very classical use of XHR (nothing original here - there are plenty of similar articles around). I took a completely different approach, requiring absolutely no page-specific client-side JS code. The use of XHR is totally transparent and the page writer doesn't have to care about it. Client-side JS detects the availability of XHR in the host browser and uses it if it exists. Otherwise, a regular form post is done. On the server side, when answering to an XHR request, Cocoon produces partial page update directives, just by adding an additional transformer (it's a filter in Cocoon parlance) to the production pipeline of the regular full page. These update directives are then parsed by the client-side JS to update page parts that need to be updated. The result is that, using a small generic client-side JS library (approx 200 lines with comments etc), you can ajaxify any kind of form or page with most often nothing to do in page templates. And it degrades gracefully to full-page reloads on non ajax-aware browsers. This is a very productive approach that avoids most classical problems of Ajax: there's no need for a lot client-side JS code that is difficult to make really cross-browser, difficult to test, avoids opening too many entry points in the application that could create security holes. So please, rather than taking attribution when it's totally unjustified, consider learning from other's ideas. Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111348478712544w=2 -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Transparent and automatic AJAX support for CForms
SNIP On 4/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote: (stupid Struts people that think the whole world reads their articles and mailing lists) /SNIP What I like most about your writing, Sylvain, is your almost poetic innate sense of assonance. The article was quoted by the post I referenced. I have to say that I am sorry that I stepped on your ego, but since it was laying across the whole landscape, it was hard to miss. Keep up the good work.
Re: Transparent and automatic AJAX support for CForms
Well, my real interest was in letting Frank Zammetti on the Struts list know about the work on Cocoon. I did not know I had to be real careful to make sure that Sylvain's sense of under-privilege was not hurt. I did not even notice he was part of the equation, frankly. I certainly don't think that Struts, or anyone else, is particularly that wonderful. Let's face it. I like programming but we are not rocket scientists. Anyway, had I imagined Sylvain would have been injured as he was, I would not have done it. I could not have imagined that, of course, since I did not even know he existed. Anyway, I have no interest in being a sounding board for people who have an easy time in feeling awful. I hope Sylvain feels better now. On 4/21/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefano Mazzocchi wrote: Michael McGrady wrote: SNIP On 4/21/05, Sylvain Wallez [EMAIL PROTECTED] wrote: (stupid Struts people that think the whole world reads their articles and mailing lists) /SNIP What I like most about your writing, Sylvain, is your almost poetic innate sense of assonance. The article was quoted by the post I referenced. I have to say that I am sorry that I stepped on your ego, but since it was laying across the whole landscape, it was hard to miss. Keep up the good work. LOL Sylvain, I'm sorry, but Michael has a point ;-) I mean, there is no reason to call somebody stupid just because he didn't know something or misunderstood something else. It's also true, Michael, that what Antonio was commenting was Sylvain's work and not on the TSS's article and saying I'll tell the Struts folks how great you guys copied them is borderline offensive when it's far from the truth, like in this case. -- Stefano.
Re: Transparent and automatic AJAX support for CForms
I did not say what you say was not true Gallardo. I should have been more careful and I would have been had I known there were fragile people out there who might be hurt. As it was, I do not take myself so seriously as some others do. Anyway, I sure did not mean to suggest that Cocoon was built by Frank Zammetti. I thought I said: Thought I'd pass on to the Struts list the great success and popularity Frank Zammetti's ideas are having on the Cocoon list. Oh, wait, I checked, and I did say that. LOL ///;-) On 4/21/05, Antonio Gallardo [EMAIL PROTECTED] wrote: On Jue, 21 de Abril de 2005, 3:07, Michael McGrady dijo: Thought I'd pass on to the Struts list the great success and popularity Frank Zammetti's ideas are having on the Cocoon list. Hi Michael, Unfortunately, I need to tell this just for the records: In cocoon XmlHttpRequest was first saw in 9-Sept-2004 thanks to Ugo Cei: $ svn log src/blocks/forms/samples/forms/xhr_carselector_template.xml snip/ r43610 | ugo | 2004-09-09 10:36:28 -0500 (jue, 09 sep 2004) | 1 line Carselector with XMLHTTPRequest sample I am not telling the article by Frank Zammetti's was not interesting. It was! The article helped me to understand AJAX. I am happy of that. But from this to tell that cocoon implemented AJAX based on the article is no true. In my post I just related how I stepped. I just posted what I was trying to do. My answer takes almost 10 days since Sylvain original post, becaue I wanted to take my time to write a good answer for this great job, because while I was doing my small AJAX steps, Sylvain showed his own solution. He was faster than me for a lot of time. I don't know when I will finish that. Kudos to Sylvain again! He is on my hero plate now! :-) BTW, I expect to see this in 2.1.x soon! ;-) Best Regards, Antonio Gallardo. On 4/20/05, Antonio Gallardo [EMAIL PROTECTED] wrote: Hi: Simply, wow, it is great! :-) I started to do something similar 4 days before you posted this solution! My main motivation was because repeater widget with comboboxes are very slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form because the repeater data. The all form was +100kB! Of course, this was an unusable solution. Then we thought that a solution was break the form in more pieces, but this looked very ugly from a user POV. At that time, Tim Larson advised to look for an XmlHttpRequest solution integrated into cforms. The same day, I saw an struts related article in the theserverside: http://theserverside.com/news/thread.tss?thread_id=33056 And I started to migrate this to cocoon in my free time. But with no major success. :-( I think, your solution is more elegant than what I tried to do. My idea was to generate client-side java script for every widget and send it to the browser, then the browser will react to the onfocus event of the widget and fill the list on demand. That way we don't need to fill all the lists at once and the page will load faster. I expected cocoon caching will help here. Also, given the fact that this solution was not needed on every combo, I thought to include an @ajax attribute in the fi namespace on the template as flag. Something similiar like I saw in the struts sample pointed above. Not at the form level as the committed solution. I have 2 questions: 1- Will this ajax implementation improve the combo loads in cforms? 2- Are you planning to merge it in 2.1.x? If not I will see the urge to move to 2.2 soon! :-D Thanks for this great improvement! Best Regards, Antonio Gallardo. On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: Hi all, I've been thinking for a few weeks to add AJAX support to CForms. Ajax is the current buzzword in the blogosphere since Google maps [1] started and the folks at Adaptivepath found this name for the XmlHttpRequest + JS + XML combo [2]. At first this looked like a complex problem, requiring a special controller and special pipelines on the server to answer ajax requests, and ajax-aware implementations of widget styling (i.e. having a JS client-side part to handle page update). Lots of code for the infrastructure, and lots of browser-dependent code each time we want to add a new styling. Then a few days ago I realized that we don't need that complexity. Form widgets have all the information needed to inform the surrounding environment if they need to be updated, and we can use this information to do partial updates of the browser page. Two days hacking, most of which dedicated to writing client-side JS and solving cross-browser compatibility problems and here we are: adding ajax=true on ft:form-template turns
Re: Transparent and automatic AJAX support for CForms
You're right. Peace! On 4/21/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Michael McGrady wrote: Well, my real interest was in letting Frank Zammetti on the Struts list know about the work on Cocoon. I did not know I had to be real careful to make sure that Sylvain's sense of under-privilege was not hurt. I did not even notice he was part of the equation, frankly. I certainly don't think that Struts, or anyone else, is particularly that wonderful. Let's face it. I like programming but we are not rocket scientists. Anyway, had I imagined Sylvain would have been injured as he was, I would not have done it. I could not have imagined that, of course, since I did not even know he existed. Anyway, I have no interest in being a sounding board for people who have an easy time in feeling awful. I hope Sylvain feels better now. Michael, that's enough. -- Stefano.
Re: Cocoon Hackathon at ApacheCon
Well, try to answer my question before you go? LOL On Apr 1, 2005 5:07 PM, peter royal [EMAIL PROTECTED] wrote: [X] there is a chance I gonna make it -pete
