cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Transparent and automatic AJAX support for CForms
Date Fri, 22 Apr 2005 05:04:53 GMT
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 <agallardo@agssa.net> 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 <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