You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/04/14 15:19:33 UTC
Transparent and automatic AJAX support for CForms
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
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Mats wrote:
> Great initiative!
>
> Sylvain Wallez wrote:
>
>> 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].
>>
>
> <snip/>
>
>> 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.
>
>
> I was just wondering if you considered using any of the cross-browser
> libraries for doing the XHR stuff?
>
> Dojo [http://dojotoolkit.org/intro_to_dojo_io.html]
Yes. Very interesting but seemed to much complex for the current need.
But it's under my radar for some more complicated stuff ;-)
> Sarissa [http://sarissa.sourceforge.net/doc/]
>
> I guess the problem with Sarissa is the licensing, it´s GPL'ed :(
Good guess...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Mats <ma...@alma.nu>.
Great initiative!
Sylvain Wallez wrote:
> 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].
>
<snip/>
> 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.
I was just wondering if you considered using any of the cross-browser
libraries for doing the XHR stuff?
Dojo [http://dojotoolkit.org/intro_to_dojo_io.html]
Sarissa [http://sarissa.sourceforge.net/doc/]
I guess the problem with Sarissa is the licensing, it´s GPL'ed :(
Best regards,
Mats
Re: Cocoon marketing
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 14.04.2005 15:19, Sylvain Wallez wrote:
>
>> Now that Cocoon has Spring and Ajax support, we really should post an
>> article on TSS ;-)
>
>
> I guess this has not happened yet ;) Cocoon was also the first web
> framework with continuations and never really made something out of
> it. We could really improve in our marketing.
Yup. We need to write articles. I'm sure they would easily be accepted
by onjava, TSS, etc. A discussion subject for the hackaton?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Cocoon marketing (was: Transparent and automatic AJAX support for
CForms)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.04.2005 15:19, Sylvain Wallez wrote:
> Now that Cocoon has Spring and Ajax support, we really should post an
> article on TSS ;-)
I guess this has not happened yet ;) Cocoon was also the first web
framework with continuations and never really made something out of it.
We could really improve in our marketing.
Jörg
Re: Transparent and automatic AJAX support for Cocoon Forms
Posted by Michael McGrady <mi...@gmail.com>.
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 <sy...@apache.org> 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-dev&m=111348478712544&w=2
>
> --
> Sylvain Wallez Anyware Technologies
> http://apache.org/~sylvain http://anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
>
>
Re: Transparent and automatic AJAX support for Cocoon Forms
Posted by Sylvain Wallez <sy...@apache.org>.
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-dev&m=111348478712544&w=2
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Antonio Gallardo <ag...@agssa.net>.
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 <ag...@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 <ag...@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
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: Transparent and automatic AJAX support for CForms
Posted by Michael McGrady <mi...@gmail.com>.
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 <ag...@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 <ag...@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
> >> >
> >>
> >>
> >
>
>
Re: Transparent and automatic AJAX support for CForms
Posted by Antonio Gallardo <ag...@agssa.net>.
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 <ag...@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
>> >
>>
>>
>
Re: Transparent and automatic AJAX support for Cocoon Forms
Posted by Sylvain Wallez <sy...@apache.org>.
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-dev&m=111348478712544&w=2
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Transparent and automatic AJAX support for CForms
Posted by Michael McGrady <mi...@gmail.com>.
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 <ag...@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
> >
>
>
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> [1] http://marc.theaimsgroup.com/?l=struts-dev&m=111408087805013&w=2
Forgot to say: this guy uses various identities. While he posted here as
"Michael McGrady", we was posting on struts-dev as "Dakota Jack"...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Michael McGrady wrote:
>
>> <SNIP>
>> On 4/21/05, Sylvain Wallez <sy...@apache.org> 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 ;-)
Sure, I easily admit it. Now my comment was related to the fact that the
link to the article came on our list _after_ our ajax implementation
came to svn. I should have been clearer about it.
Now it also appears that this guy is regularily trolling on Struts lists
[1]. He was pretty good at this here, but now we're warned.
I also feel sorry to have generalized to all struts people and would
like to apologize, hoping they were'nt offended if they've read it.
Sylvain
[1] http://marc.theaimsgroup.com/?l=struts-dev&m=111408087805013&w=2
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Michael McGrady <mi...@gmail.com>.
You're right. Peace!
On 4/21/05, Stefano Mazzocchi <st...@apache.org> 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: Transparent and automatic AJAX support for CForms
Posted by Stefano Mazzocchi <st...@apache.org>.
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: Transparent and automatic AJAX support for CForms
Posted by Michael McGrady <mi...@gmail.com>.
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 <st...@apache.org> wrote:
> Stefano Mazzocchi wrote:
> > Michael McGrady wrote:
> >
> >> <SNIP>
> >> On 4/21/05, Sylvain Wallez <sy...@apache.org> 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
Posted by Stefano Mazzocchi <st...@apache.org>.
Stefano Mazzocchi wrote:
> Michael McGrady wrote:
>
>> <SNIP>
>> On 4/21/05, Sylvain Wallez <sy...@apache.org> 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
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael McGrady wrote:
> <SNIP>
> On 4/21/05, Sylvain Wallez <sy...@apache.org> 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 ;-)
--
Stefano.
Re: Transparent and automatic AJAX support for CForms
Posted by Michael McGrady <mi...@gmail.com>.
<SNIP>
On 4/21/05, Sylvain Wallez <sy...@apache.org> 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
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>Hi:
>
>Simply, wow, it is great! :-)
>
>
Thanks :-)
(stupid Struts people that think the whole world reads their articles
and mailing lists)
>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.
>
>
The current solution makes Ajax totally transparent and is suitable for
most cases and requires no specific client-side JS, but is not the most
optimal for some frequent use cases such as populating dropdowns.
So a second phase of Ajax-in-Cocoon is to write some "ajax-aware"
stylings, that provide some finer-grained updates or some additional
behaviour. And these styling will be triggered as usual in <fi:styling>,
e.g. <fi:styling type="ajax-dropdown">
>I have 2 questions:
>
>1- Will this ajax implementation improve the combo loads in cforms?
>
>
What do you mean by "combo loads"? If this is changing selection lists,
then it already does it (see the carselector). If it's lazily populating
dropdowns when the user clicks on them, this should be part of the
second phased described above.
>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
>
>
Yes, sure this will go to 2.1.x. It's currently in 2.2 only as I wanted
to gather people's feeback on this original approach.
>Thanks for this great improvement!
>
>
Thanks :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Antonio Gallardo <ag...@agssa.net>.
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
>
Re: Transparent and automatic AJAX support for CForms
Posted by Tony Collen <co...@umn.edu>.
Jeremy Quinn wrote:
> Hi Sylvain,
>
> I get the same problems with Safari 2.0 (412) with Tiger.
>
> This is just a warning for anyone wanting to use this new Ajax stuff
> for real projects ...... this stuff does not degrade gracefully, it
> just breaks in this browser.
Could try turning on the Safari debug menu -- type "defaults write
com.apple.safari IncludeDebugMenu 1" at the command prompt and restart
Safari -- and see if there are helpful things for tracking down what the
problem is, exactly.
Tony
Re: Transparent and automatic AJAX support for CForms
Posted by Jeremy Quinn <je...@luminas.co.uk>.
On 23 Jun 2005, at 10:23, Sylvain Wallez wrote:
> Jeremy Quinn wrote:
>
>
>> I have seen other 'Ajax' type frameworks that allegedly work on
>> Safari, so there must be some solution (?)
>>
>
>
> Fixed! I added a workaround in Forms.js to always send something
> back to the browser, rather than just some headers and a content-
> length=0.
>
> Please cross-check!
It's working !!!!!
Many Thanks Sylvain !!!!
regards Jeremy
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
> I have seen other 'Ajax' type frameworks that allegedly work on
> Safari, so there must be some solution (?)
Fixed! I added a workaround in Forms.js to always send something back to
the browser, rather than just some headers and a content-length=0.
Please cross-check!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Tony Collen <co...@umn.edu>.
Jeremy Quinn wrote:
> I have seen other 'Ajax' type frameworks that allegedly work on Safari,
> so there must be some solution (?)
>
> regards Jeremy
How about returning an empty root tag instead of no root tag?
Unless I am misunderstanding "responses of zero length"
Tony
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
>
> On 22 Jun 2005, at 10:01, Sylvain Wallez wrote:
>
>> Gregor J. Rothfuss wrote:
>>
>>
>>> Sylvain Wallez wrote:
>>>
>>>
>>>> Don't be! The issue with Safari is that its XMLHttpRequest doesn't
>>>> seem to consider responses of length zero as valid, which Firefox
>>>> and IE do.
>>>>
>>>> The problem is that fixing this will require to add an additional
>>>> ajax-specific pipeline in each cforms sitemap, which I would like
>>>> to avoid.
>>>>
>>>
>>>
>>> http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit
>>>
>>
>>
>> Sure. Funny thing is that existing entries for WebKit are mostly
>> about XHR!
>
>
> I have seen other 'Ajax' type frameworks that allegedly work on
> Safari, so there must be some solution (?)
Yes, but they certainly don't use responses with zero-length content
(i.e. just headers) which is what is used in CForms to indicate that
interaction on the form is finished and that the full page should be
reloaded. And that's this zero-length response that seem to have
problems with Safari.
It is possible to circumvent this by always sending a response, but I'd
like to avoid this as far as possible, as it would require an additional
pipeline in the sitemap just for this purpose. That's why I want to
investigate further this Safari problem before going to that
unsatisfying solution.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Jeremy Quinn <je...@apache.org>.
On 22 Jun 2005, at 10:01, Sylvain Wallez wrote:
> Gregor J. Rothfuss wrote:
>
>
>> Sylvain Wallez wrote:
>>
>>
>>> Don't be! The issue with Safari is that its XMLHttpRequest
>>> doesn't seem to consider responses of length zero as valid, which
>>> Firefox and IE do.
>>>
>>> The problem is that fixing this will require to add an additional
>>> ajax-specific pipeline in each cforms sitemap, which I would like
>>> to avoid.
>>>
>>
>>
>> http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit
>>
>
>
> Sure. Funny thing is that existing entries for WebKit are mostly
> about XHR!
I have seen other 'Ajax' type frameworks that allegedly work on
Safari, so there must be some solution (?)
regards Jeremy
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Gregor J. Rothfuss wrote:
> Sylvain Wallez wrote:
>
>> Don't be! The issue with Safari is that its XMLHttpRequest doesn't
>> seem to consider responses of length zero as valid, which Firefox and
>> IE do.
>>
>> The problem is that fixing this will require to add an additional
>> ajax-specific pipeline in each cforms sitemap, which I would like to
>> avoid.
>
>
> http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit
Sure. Funny thing is that existing entries for WebKit are mostly about XHR!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Sylvain Wallez wrote:
> Don't be! The issue with Safari is that its XMLHttpRequest doesn't seem
> to consider responses of length zero as valid, which Firefox and IE do.
>
> The problem is that fixing this will require to add an additional
> ajax-specific pipeline in each cforms sitemap, which I would like to avoid.
http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit
:)
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
> Hi Sylvain,
>
> I get the same problems with Safari 2.0 (412) with Tiger.
>
> This is just a warning for anyone wanting to use this new Ajax stuff
> for real projects ...... this stuff does not degrade gracefully, it
> just breaks in this browser.
>
> Sorry
Don't be! The issue with Safari is that its XMLHttpRequest doesn't seem
to consider responses of length zero as valid, which Firefox and IE do.
The problem is that fixing this will require to add an additional
ajax-specific pipeline in each cforms sitemap, which I would like to avoid.
I haven't had time to investigate on this Safari-specific issue. In the
meantime, I think the quickest fix is to disable Ajax when running on
Safari (boohooo...). I'll do that ASAP.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Jeremy Quinn <je...@apache.org>.
Hi Sylvain,
I get the same problems with Safari 2.0 (412) with Tiger.
This is just a warning for anyone wanting to use this new Ajax stuff
for real projects ...... this stuff does not degrade gracefully, it
just breaks in this browser.
Sorry
regards Jeremy
On 23 Apr 2005, at 13:47, Sylvain Wallez wrote:
> Jeremy Quinn wrote:
>
>
>>
>> On 14 Apr 2005, at 14:19, Sylvain Wallez wrote:
>>
>>
>>> 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
>>>
>>
>>
>> This is just so cool, Sylvain !!!!
>>
>> Sorry to say but I am having some problems with the samples though.
>>
>> In Safari 1.3 (v312) the latest, the carselector works fine,
>> however the other three pop up a javascript error dialog on submit:
>>
>> JavaScript
>> request failed: undefined
>>
>> Looking at the MacOSX console.log, I see the line :
>>
>> (event handler):Undefined value
>>
>> appearing each time I enter data in a field, then a final one when
>> I submit.
>>
>> This happens with all of the samples, but the carselector still
>> works.
>>
>
>
> Hmm... damn cross-browser issues. I'll take a look at that.
>
> Thanks for the feedback!
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://apache.org/~sylvain http://anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
>
>
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Jeremy Quinn wrote:
>
> On 14 Apr 2005, at 14:19, Sylvain Wallez wrote:
>
>> 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
>
>
> This is just so cool, Sylvain !!!!
>
> Sorry to say but I am having some problems with the samples though.
>
> In Safari 1.3 (v312) the latest, the carselector works fine, however
> the other three pop up a javascript error dialog on submit:
>
> JavaScript
> request failed: undefined
>
> Looking at the MacOSX console.log, I see the line :
>
> (event handler):Undefined value
>
> appearing each time I enter data in a field, then a final one when I
> submit.
>
> This happens with all of the samples, but the carselector still works.
Hmm... damn cross-browser issues. I'll take a look at that.
Thanks for the feedback!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Jeremy Quinn <je...@apache.org>.
On 14 Apr 2005, at 14:19, Sylvain Wallez wrote:
> 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
This is just so cool, Sylvain !!!!
Sorry to say but I am having some problems with the samples though.
In Safari 1.3 (v312) the latest, the carselector works fine, however
the other three pop up a javascript error dialog on submit:
JavaScript
request failed: undefined
Looking at the MacOSX console.log, I see the line :
(event handler):Undefined value
appearing each time I enter data in a field, then a final one when I
submit.
This happens with all of the samples, but the carselector still works.
best regards
Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: Transparent and automatic AJAX support for CForms
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Ben Pope wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> 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].
>>>
>>>
>>>
>>>
>>> <snip/>
>>>
>>>> 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.
>>>
>>>
>>>
>>>
>>> <snip/>
>>>
>>>> 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
>>>
>>>
>>>
>>>
>>> <snip/>
>>>
>>>> Enjoy,
>>>> Sylvain
>>>
>>>
>>>
>>>
>>> Well I have only just read this mail, and haven't had a chance to
>>> look at the samples, but it looks pretty useful to me. I'll look
>>> into it soon.
>>>
>>> Nice one Silvain... I'm sure there are others that appreciate this
>>> effort.
>>
>>
>>
>> It looks really promising. I was not able to run the samples. Firefox
>> has rendered the retrieved list as text (outside selection widget). IE
>> just showed javascript error and did nothing.
>
>
>
> Doh! I understand why you say "promising" :-(
>
> I tested it successfully with Firefox 1.0 on MacOS and Windows and IE 6.
> The behaviour you describe with Firefox is what I had to fight a lot
> with: Node.importNode() effectively imports nodes, but that doesn't mean
> they're considered as HTML nodes, in which case only their text is
> displayed.
>
> If you look at the new DOMUtils.importNode() in the new cforms.js,
> you'll see the quirks I used to workaround this weirdness: use ".xml"
> and ".innerHTML" properties with IE, and traverse the node tree for
> other browsers. I'm far from being a JS-on-browsers expert, so that may
> for sure not be the most "compatible" solution.
>
> Is there something printed in Firefox's JS console, and what is the IE
> error?
I'll recheck it this evening and give you as much feedback as possible.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Ben Pope wrote:
> Sylvain Wallez wrote:
>
>> This is the XHR-powered carselector Ugo added months ago as a first
>> experiment. Try the "regular" carselector, and also "dynamic
>> repeater", "datasource selector" and "task tree" (right column).
>
>
> I did wonder, as it wasn't what you'd mentioned.
>
> However, Firefox renders carselector fine, and IE is also quite happy.
>
> The carselector uses form submit "onChange", and doesn't need Ajax? I
> also don't see the need for Ajax in the other samples.
Well, you don't see it as these already were dynamic form samples ;-)
The important difference is that only some parts of the page are
updated, rather than the full page. It doesn't make much difference on
these simple samples, but will on more complex forms or layouts.
About the "submit-on-change", I have not changed the semantics behind it
and it's still required in order for roundtripping to the server to
occur. But I really think this attribute is now rather useless and
should be implicit as soon as a widget has an attached event listener.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> This is the XHR-powered carselector Ugo added months ago as a first
> experiment. Try the "regular" carselector, and also "dynamic repeater",
> "datasource selector" and "task tree" (right column).
I did wonder, as it wasn't what you'd mentioned.
However, Firefox renders carselector fine, and IE is also quite happy.
The carselector uses form submit "onChange", and doesn't need Ajax? I
also don't see the need for Ajax in the other samples.
I really need to take a closer look at these samples!
I'll stop with the noise until I've had a closer look.
Ben
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Ben Pope wrote:
> Sylvain Wallez wrote:
>
>> Leszek Gawron wrote:
>>
>>> It looks really promising. I was not able to run the samples.
>>> Firefox has rendered the retrieved list as text (outside selection
>>> widget). IE just showed javascript error and did nothing.
>>
>>
>>
>>
>> Doh! I understand why you say "promising" :-(
>>
>> I tested it successfully with Firefox 1.0 on MacOS and Windows and IE
>> 6. The behaviour you describe with Firefox is what I had to fight a
>> lot with: Node.importNode() effectively imports nodes, but that
>> doesn't mean they're considered as HTML nodes, in which case only
>> their text is displayed.
>>
>> If you look at the new DOMUtils.importNode() in the new cforms.js,
>> you'll see the quirks I used to workaround this weirdness: use ".xml"
>> and ".innerHTML" properties with IE, and traverse the node tree for
>> other browsers. I'm far from being a JS-on-browsers expert, so that
>> may for sure not be the most "compatible" solution.
>>
>> Is there something printed in Firefox's JS console, and what is the
>> IE error?
>
>
> I.e. says:
> Line: 91
> Char: 5
> Error: Object doesn't support this property or method.
> Code: 0
>
> The line in question:
> xmlhttp.open("GET", "xhr_cars/" + make.value, true);
>
> Perhaps thats make.value with the problem?
Funnily, you're not looking at the Ajax framework I added ;-)
This is the XHR-powered carselector Ugo added months ago as a first
experiment. Try the "regular" carselector, and also "dynamic repeater",
"datasource selector" and "task tree" (right column).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>> It looks really promising. I was not able to run the samples. Firefox
>> has rendered the retrieved list as text (outside selection widget). IE
>> just showed javascript error and did nothing.
>
>
>
> Doh! I understand why you say "promising" :-(
>
> I tested it successfully with Firefox 1.0 on MacOS and Windows and IE 6.
> The behaviour you describe with Firefox is what I had to fight a lot
> with: Node.importNode() effectively imports nodes, but that doesn't mean
> they're considered as HTML nodes, in which case only their text is
> displayed.
>
> If you look at the new DOMUtils.importNode() in the new cforms.js,
> you'll see the quirks I used to workaround this weirdness: use ".xml"
> and ".innerHTML" properties with IE, and traverse the node tree for
> other browsers. I'm far from being a JS-on-browsers expert, so that may
> for sure not be the most "compatible" solution.
>
> Is there something printed in Firefox's JS console, and what is the IE
> error?
I.e. says:
Line: 91
Char: 5
Error: Object doesn't support this property or method.
Code: 0
The line in question:
xmlhttp.open("GET", "xhr_cars/" + make.value, true);
Perhaps thats make.value with the problem?
Firefox on Windows doesn't say anything, it's quite happy.
Ben
Re: Transparent and automatic AJAX support for CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
<snip/>
> Doh! I understand why you say "promising" :-(
>
> I tested it successfully with Firefox 1.0 on MacOS and Windows and IE 6.
> The behaviour you describe with Firefox is what I had to fight a lot
> with: Node.importNode() effectively imports nodes, but that doesn't mean
> they're considered as HTML nodes, in which case only their text is
> displayed.
I hate this behaviour, I implemented an "AJAX" menu tree (dynamic
downloading and uppdating of sub menues) for our internal webapps long
time ago. I developed it for IE usage and have spent quite some time
trying to port it to Mozilla and Firefox whithout success :(
> If you look at the new DOMUtils.importNode() in the new cforms.js,
> you'll see the quirks I used to workaround this weirdness: use ".xml"
> and ".innerHTML" properties with IE, and traverse the node tree for
> other browsers. I'm far from being a JS-on-browsers expert, so that may
> for sure not be the most "compatible" solution.
Will take a look at your workarounds.
/Daniel
Re: Transparent and automatic AJAX support for CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Ben Pope wrote:
>
>> Sylvain Wallez wrote:
>>
>>> 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].
>>
>>
>>
>> <snip/>
>>
>>> 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.
>>
>>
>>
>> <snip/>
>>
>>> 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
>>
>>
>>
>> <snip/>
>>
>>> Enjoy,
>>> Sylvain
>>
>>
>>
>> Well I have only just read this mail, and haven't had a chance to
>> look at the samples, but it looks pretty useful to me. I'll look
>> into it soon.
>>
>> Nice one Silvain... I'm sure there are others that appreciate this
>> effort.
>
>
> It looks really promising. I was not able to run the samples. Firefox
> has rendered the retrieved list as text (outside selection widget). IE
> just showed javascript error and did nothing.
Doh! I understand why you say "promising" :-(
I tested it successfully with Firefox 1.0 on MacOS and Windows and IE 6.
The behaviour you describe with Firefox is what I had to fight a lot
with: Node.importNode() effectively imports nodes, but that doesn't mean
they're considered as HTML nodes, in which case only their text is
displayed.
If you look at the new DOMUtils.importNode() in the new cforms.js,
you'll see the quirks I used to workaround this weirdness: use ".xml"
and ".innerHTML" properties with IE, and traverse the node tree for
other browsers. I'm far from being a JS-on-browsers expert, so that may
for sure not be the most "compatible" solution.
Is there something printed in Firefox's JS console, and what is the IE
error?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ben Pope wrote:
> Sylvain Wallez wrote:
>
>> 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].
>
>
> <snip/>
>
>> 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.
>
>
> <snip/>
>
>> 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
>
>
> <snip/>
>
>> Enjoy,
>> Sylvain
>
>
> Well I have only just read this mail, and haven't had a chance to look
> at the samples, but it looks pretty useful to me. I'll look into it soon.
>
> Nice one Silvain... I'm sure there are others that appreciate this effort.
It looks really promising. I was not able to run the samples. Firefox
has rendered the retrieved list as text (outside selection widget). IE
just showed javascript error and did nothing.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Transparent and automatic AJAX support for CForms
Posted by Ben Pope <be...@gmail.com>.
Sylvain Wallez wrote:
> 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].
<snip/>
> 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.
<snip/>
> 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
<snip/>
> Enjoy,
> Sylvain
Well I have only just read this mail, and haven't had a chance to look
at the samples, but it looks pretty useful to me. I'll look into it soon.
Nice one Silvain... I'm sure there are others that appreciate this effort.
Ben