Here is a post on Cocoon, which show the present end of a long series of posts using Frank Zammetti's idea propounded here and elsewhere, see the attribution in this posting. Cannot tell which list to post this to and I realize that everyone is going to ape sh__ over this because ..................., but here is the source for those actively following these ideas. My apologies if this is mistaken.
Jack 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 > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
