On Jue, 21 de Abril de 2005, 23:53, Michael McGrady dijo: > 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.
Please read carefully my mail. I never wrote: "Anyway, I sure did not mean to suggest that Cocoon was built by Frank Zammetti." Anyway, this thread is being a totally non-sense now. I don't plan to reply your mails again. Let's move on! Best Regards, Antonio Gallardo. > 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 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 >> >> instance >> >> > need to have the same id attribute as the widget. >> >> > >> >> > This constraint is satisfied for all field stylings (I updated the >> >> > stylesheets), but not always for containers (repeaters, structs, >> etc). >> >> > >> >> > About repeater, this requires a change in the template language, to >> >> > separate the repeater itself from the iteration on its rows. So >> rather >> >> > than: >> >> > <table> >> >> > <!-- header --> >> >> > <ft:repeater-widget id="myrepeater"> >> >> > <!-- row --> >> >> > </ft:repeater-widget> >> >> > </table> >> >> > >> >> > we now have to write: >> >> > <ft:repeater id="myrepeater"> >> >> > <table> >> >> > <!-- header --> >> >> > <ft:repeater-rows> >> >> > <!-- row --> >> >> > </ft:repeater-rows> >> >> > </table> >> >> > </ft:repeater> >> >> > >> >> > I have turned on ajax mode on the following samples: >> >> > - http://localhost:8888/forms-samples/carselector >> >> > - http://localhost:8888/forms-samples/do-dynaRepeater.flow >> >> > - http://localhost:8888/forms-samples/do-datasourceChooser.flow >> >> > - http://localhost:8888/forms-samples/do-taskTree.flow >> >> > >> >> > -- oOo -- >> >> > >> >> > Next steps are better handling of container widgets and >> finer-grained >> >> > browser update for some often-used stylings such as dropdowns and >> >> inputs. >> >> > >> >> > Now that Cocoon has Spring and Ajax support, we really should post >> an >> >> > article on TSS ;-) >> >> > >> >> > Enjoy, >> >> > Sylvain >> >> > >> >> > [1] http://maps.google.com/ >> >> > [2] >> >> http://www.adaptivepath.com/publications/essays/archives/000385.php >> >> > >> >> > -- >> >> > Sylvain Wallez Anyware Technologies >> >> > http://apache.org/~sylvain http://anyware-tech.com >> >> > Apache Software Foundation Member Research & Technology >> Director >> >> > >> >> >> >> >> > >> >> >
