cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <michael.mcgr...@gmail.com>
Subject Re: Transparent and automatic AJAX support for CForms
Date Thu, 21 Apr 2005 08:07:30 GMT
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 <agallardo@agssa.net> 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
> >
> 
>

Mime
View raw message