Re: Transparent and automatic AJAX support for CForms
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 smime.p7s Description: S/MIME cryptographic signature
Re: Transparent and automatic AJAX support for CForms
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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
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 smime.p7s Description: S/MIME cryptographic signature
Re: Transparent and automatic AJAX support for CForms
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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
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:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director smime.p7s Description: S/MIME cryptographic signature
Re: Transparent and automatic AJAX support for CForms
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:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
On 14 Apr 2005, at 14:19, Sylvain Wallez wrote: I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/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 ! smime.p7s Description: S/MIME cryptographic signature
Re: Transparent and automatic AJAX support for CForms
On Jue, 21 de Abril de 2005, 23:53, Michael McGrady dijo: > I did not say what you say was "not true" Gallardo. I should have > been more careful and I would have been had I known there were fragile > people out there who might be hurt. As it was, I do not take myself > so seriously as some others do. Anyway, I sure did not mean to > suggest that Cocoon was built by Frank Zammetti. Please read carefully my mail. I never wrote: "Anyway, I sure did not mean to suggest that Cocoon was built by Frank Zammetti." Anyway, this thread is being a totally non-sense now. I don't plan to reply your mails again. Let's move on! Best Regards, Antonio Gallardo. > I thought I said: > "Thought I'd pass on to the Struts list the great success and > popularity Frank Zammetti's ideas are having on the Cocoon list." Oh, > wait, I checked, and I did say that. LOL ///;-) > > On 4/21/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: >> On Jue, 21 de Abril de 2005, 3:07, Michael McGrady dijo: >> > Thought I'd pass on to the Struts list the great success and >> > popularity Frank Zammetti's ideas are having on the Cocoon list. >> >> Hi Michael, >> >> Unfortunately, I need to tell this just for the records: >> >> In cocoon XmlHttpRequest was first saw in 9-Sept-2004 thanks to Ugo Cei: >> >> $ svn log src/blocks/forms/samples/forms/xhr_carselector_template.xml >> >> >> >> r43610 | ugo | 2004-09-09 10:36:28 -0500 (jue, 09 sep 2004) | 1 line >> >> Carselector with XMLHTTPRequest sample >> >> >> I am not telling the article by Frank Zammetti's was not interesting. It >> was! The article helped me to understand AJAX. I am happy of that. But >> from this to tell that cocoon implemented AJAX based on the article is >> no >> true. >> >> In my post I just related how I stepped. I just posted what I was trying >> to do. My answer takes almost 10 days since Sylvain original post, >> becaue >> I wanted to take my time to write a good answer for this great job, >> because while I was doing my small AJAX steps, Sylvain showed his own >> solution. He was faster than me for a lot of time. I don't know when I >> will finish that. >> >> Kudos to Sylvain again! He is on my hero plate now! :-) >> >> BTW, I expect to see this in 2.1.x soon! ;-) >> >> Best Regards, >> >> Antonio Gallardo. >> >> > >> > >> > On 4/20/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: >> >> Hi: >> >> >> >> Simply, wow, it is great! :-) >> >> >> >> I started to do something similar 4 days before you posted this >> >> solution! >> >> >> >> My main motivation was because repeater widget with comboboxes are >> very >> >> slow in 2.1.x. I saw a browser waiting around 2 minutes to show a >> form >> >> because the repeater data. The all form was +100kB! Of course, this >> was >> >> an >> >> unusable solution. Then we thought that a solution was break the form >> in >> >> more pieces, but this looked very ugly from a user POV. >> >> >> >> At that time, Tim Larson advised to look for an XmlHttpRequest >> solution >> >> integrated into cforms. The same day, I saw an struts related article >> in >> >> the theserverside: >> >> >> >> http://theserverside.com/news/thread.tss?thread_id=33056 >> >> >> >> And I started to migrate this to cocoon in my free time. But with no >> >> major >> >> success. :-( >> >> >> >> I think, your solution is more elegant than what I tried to do. My >> idea >> >> was to generate client-side java script for every widget and send it >> to >> >> the browser, then the browser will react to the onfocus event of the >> >> widget and fill the list on demand. That way we don't need to fill >> all >> >> the >> >> lists at once and the page will load faster. I expected cocoon >> caching >> >> will help here. >> >> >> >> Also, given the fact that this solution was not needed on every >> combo, I >> >> thought to include an @ajax attribute in the "fi" namespace on the >> >> template as flag. Something similiar like I saw in the struts sample >> >> pointed above. Not at the form level as the committed solution. >> >> >> >> I have 2 questions: >> >> >> >> 1- Will this ajax implementation improve the combo loads in cforms? >> >> 2- Are you planning to merge it in 2.1.x? If not I will see the urge >> to >> >> move to 2.2 soon! :-D >> >> >> >> Thanks for this great improvement! >> >> >> >> Best Regards, >> >> >> >> Antonio Gallardo. >> >> >> >> On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: >> >> > Hi all, >> >> > >> >> > I've been thinking for a few weeks to add AJAX support to CForms. >> Ajax >> >> > is the current buzzword in the blogosphere since Google maps [1] >> >> started >> >> > and the folks at Adaptivepath found this name for the >> XmlHttpRequest + >> >> > JS + XML combo [2]. >> >> > >> >> > At first this looked like a complex problem, requiring a special >> >> > controller and special pipelines on the ser
Re: Transparent and automatic AJAX support for CForms
You're right. Peace! On 4/21/05, Stefano Mazzocchi <[EMAIL PROTECTED]> 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
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
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 <[EMAIL PROTECTED]> wrote: > On Jue, 21 de Abril de 2005, 3:07, Michael McGrady dijo: > > Thought I'd pass on to the Struts list the great success and > > popularity Frank Zammetti's ideas are having on the Cocoon list. > > Hi Michael, > > Unfortunately, I need to tell this just for the records: > > In cocoon XmlHttpRequest was first saw in 9-Sept-2004 thanks to Ugo Cei: > > $ svn log src/blocks/forms/samples/forms/xhr_carselector_template.xml > > > > r43610 | ugo | 2004-09-09 10:36:28 -0500 (jue, 09 sep 2004) | 1 line > > Carselector with XMLHTTPRequest sample > > > I am not telling the article by Frank Zammetti's was not interesting. It > was! The article helped me to understand AJAX. I am happy of that. But > from this to tell that cocoon implemented AJAX based on the article is no > true. > > In my post I just related how I stepped. I just posted what I was trying > to do. My answer takes almost 10 days since Sylvain original post, becaue > I wanted to take my time to write a good answer for this great job, > because while I was doing my small AJAX steps, Sylvain showed his own > solution. He was faster than me for a lot of time. I don't know when I > will finish that. > > Kudos to Sylvain again! He is on my hero plate now! :-) > > BTW, I expect to see this in 2.1.x soon! ;-) > > Best Regards, > > Antonio Gallardo. > > > > > > > On 4/20/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: > >> Hi: > >> > >> Simply, wow, it is great! :-) > >> > >> I started to do something similar 4 days before you posted this > >> solution! > >> > >> My main motivation was because repeater widget with comboboxes are very > >> slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form > >> because the repeater data. The all form was +100kB! Of course, this was > >> an > >> unusable solution. Then we thought that a solution was break the form in > >> more pieces, but this looked very ugly from a user POV. > >> > >> At that time, Tim Larson advised to look for an XmlHttpRequest solution > >> integrated into cforms. The same day, I saw an struts related article in > >> the theserverside: > >> > >> http://theserverside.com/news/thread.tss?thread_id=33056 > >> > >> And I started to migrate this to cocoon in my free time. But with no > >> major > >> success. :-( > >> > >> I think, your solution is more elegant than what I tried to do. My idea > >> was to generate client-side java script for every widget and send it to > >> the browser, then the browser will react to the onfocus event of the > >> widget and fill the list on demand. That way we don't need to fill all > >> the > >> lists at once and the page will load faster. I expected cocoon caching > >> will help here. > >> > >> Also, given the fact that this solution was not needed on every combo, I > >> thought to include an @ajax attribute in the "fi" namespace on the > >> template as flag. Something similiar like I saw in the struts sample > >> pointed above. Not at the form level as the committed solution. > >> > >> I have 2 questions: > >> > >> 1- Will this ajax implementation improve the combo loads in cforms? > >> 2- Are you planning to merge it in 2.1.x? If not I will see the urge to > >> move to 2.2 soon! :-D > >> > >> Thanks for this great improvement! > >> > >> Best Regards, > >> > >> Antonio Gallardo. > >> > >> On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: > >> > Hi all, > >> > > >> > I've been thinking for a few weeks to add AJAX support to CForms. Ajax > >> > is the current buzzword in the blogosphere since Google maps [1] > >> started > >> > and the folks at Adaptivepath found this name for the XmlHttpRequest + > >> > JS + XML combo [2]. > >> > > >> > At first this looked like a complex problem, requiring a special > >> > controller and special pipelines on the server to answer ajax > >> requests, > >> > and "ajax-aware" implementations of widget styling (i.e. having a JS > >> > client-side part to handle page update). Lots of code for the > >> > infrastructure, and lots of browser-dependent code each time we want > >> to > >> > add a new styling. > >> > > >> > Then a few days ago I realized that we don't need that complexity. > >> Form > >> > widgets have all the information needed to inform the surrounding > >> > environment if they need to be
Re: Transparent and automatic AJAX support for CForms
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 <[EMAIL PROTECTED]> wrote: > Stefano Mazzocchi wrote: > > Michael McGrady wrote: > > > >> > >> On 4/21/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > >> > >>> (stupid Struts people that think the whole world reads their articles > >>> and mailing lists) > >> > >> > >> > >> > >> 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
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 r43610 | ugo | 2004-09-09 10:36:28 -0500 (jue, 09 sep 2004) | 1 line Carselector with XMLHTTPRequest sample I am not telling the article by Frank Zammetti's was not interesting. It was! The article helped me to understand AJAX. I am happy of that. But from this to tell that cocoon implemented AJAX based on the article is no true. In my post I just related how I stepped. I just posted what I was trying to do. My answer takes almost 10 days since Sylvain original post, becaue I wanted to take my time to write a good answer for this great job, because while I was doing my small AJAX steps, Sylvain showed his own solution. He was faster than me for a lot of time. I don't know when I will finish that. Kudos to Sylvain again! He is on my hero plate now! :-) BTW, I expect to see this in 2.1.x soon! ;-) Best Regards, Antonio Gallardo. > > > On 4/20/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: >> Hi: >> >> Simply, wow, it is great! :-) >> >> I started to do something similar 4 days before you posted this >> solution! >> >> My main motivation was because repeater widget with comboboxes are very >> slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form >> because the repeater data. The all form was +100kB! Of course, this was >> an >> unusable solution. Then we thought that a solution was break the form in >> more pieces, but this looked very ugly from a user POV. >> >> At that time, Tim Larson advised to look for an XmlHttpRequest solution >> integrated into cforms. The same day, I saw an struts related article in >> the theserverside: >> >> http://theserverside.com/news/thread.tss?thread_id=33056 >> >> And I started to migrate this to cocoon in my free time. But with no >> major >> success. :-( >> >> I think, your solution is more elegant than what I tried to do. My idea >> was to generate client-side java script for every widget and send it to >> the browser, then the browser will react to the onfocus event of the >> widget and fill the list on demand. That way we don't need to fill all >> the >> lists at once and the page will load faster. I expected cocoon caching >> will help here. >> >> Also, given the fact that this solution was not needed on every combo, I >> thought to include an @ajax attribute in the "fi" namespace on the >> template as flag. Something similiar like I saw in the struts sample >> pointed above. Not at the form level as the committed solution. >> >> I have 2 questions: >> >> 1- Will this ajax implementation improve the combo loads in cforms? >> 2- Are you planning to merge it in 2.1.x? If not I will see the urge to >> move to 2.2 soon! :-D >> >> Thanks for this great improvement! >> >> Best Regards, >> >> Antonio Gallardo. >> >> On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: >> > Hi all, >> > >> > I've been thinking for a few weeks to add AJAX support to CForms. Ajax >> > is the current buzzword in the blogosphere since Google maps [1] >> started >> > and the folks at Adaptivepath found this name for the XmlHttpRequest + >> > JS + XML combo [2]. >> > >> > At first this looked like a complex problem, requiring a special >> > controller and special pipelines on the server to answer ajax >> requests, >> > and "ajax-aware" implementations of widget styling (i.e. having a JS >> > client-side part to handle page update). Lots of code for the >> > infrastructure, and lots of browser-dependent code each time we want >> to >> > add a new styling. >> > >> > Then a few days ago I realized that we don't need that complexity. >> Form >> > widgets have all the information needed to inform the surrounding >> > environment if they need to be updated, and we can use this >> information >> > to do partial updates of the browser page. >> > >> > Two days hacking, most of which dedicated to writing client-side JS >> and >> > solving cross-browser compatibility problems and here we are: adding >> > ajax="true" on 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 eleme
Re: Transparent and automatic AJAX support for CForms
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Stefano Mazzocchi wrote: Michael McGrady wrote: On 4/21/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: (stupid Struts people that think the whole world reads their articles and mailing lists) 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
Stefano Mazzocchi wrote: Michael McGrady wrote: On 4/21/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: (stupid Struts people that think the whole world reads their articles and mailing lists) 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
Michael McGrady wrote: On 4/21/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: (stupid Struts people that think the whole world reads their articles and mailing lists) 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
On 4/21/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > (stupid Struts people that think the whole world reads their articles > and mailing lists) 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
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 , e.g. 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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 <[EMAIL PROTECTED]> wrote: > Hi: > > Simply, wow, it is great! :-) > > I started to do something similar 4 days before you posted this solution! > > My main motivation was because repeater widget with comboboxes are very > slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form > because the repeater data. The all form was +100kB! Of course, this was an > unusable solution. Then we thought that a solution was break the form in > more pieces, but this looked very ugly from a user POV. > > At that time, Tim Larson advised to look for an XmlHttpRequest solution > integrated into cforms. The same day, I saw an struts related article in > the theserverside: > > http://theserverside.com/news/thread.tss?thread_id=33056 > > And I started to migrate this to cocoon in my free time. But with no major > success. :-( > > I think, your solution is more elegant than what I tried to do. My idea > was to generate client-side java script for every widget and send it to > the browser, then the browser will react to the onfocus event of the > widget and fill the list on demand. That way we don't need to fill all the > lists at once and the page will load faster. I expected cocoon caching > will help here. > > Also, given the fact that this solution was not needed on every combo, I > thought to include an @ajax attribute in the "fi" namespace on the > template as flag. Something similiar like I saw in the struts sample > pointed above. Not at the form level as the committed solution. > > I have 2 questions: > > 1- Will this ajax implementation improve the combo loads in cforms? > 2- Are you planning to merge it in 2.1.x? If not I will see the urge to > move to 2.2 soon! :-D > > Thanks for this great improvement! > > Best Regards, > > Antonio Gallardo. > > On Jue, 14 de Abril de 2005, 8:19, Sylvain Wallez dijo: > > Hi all, > > > > I've been thinking for a few weeks to add AJAX support to CForms. Ajax > > is the current buzzword in the blogosphere since Google maps [1] started > > and the folks at Adaptivepath found this name for the XmlHttpRequest + > > JS + XML combo [2]. > > > > At first this looked like a complex problem, requiring a special > > controller and special pipelines on the server to answer ajax requests, > > and "ajax-aware" implementations of widget styling (i.e. having a JS > > client-side part to handle page update). Lots of code for the > > infrastructure, and lots of browser-dependent code each time we want to > > add a new styling. > > > > Then a few days ago I realized that we don't need that complexity. Form > > widgets have all the information needed to inform the surrounding > > environment if they need to be updated, and we can use this information > > to do partial updates of the browser page. > > > > Two days hacking, most of which dedicated to writing client-side JS and > > solving cross-browser compatibility problems and here we are: adding > > ajax="true" on 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. > > > >
Re: Transparent and automatic AJAX support for CForms
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 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 re
Re: Transparent and automatic AJAX support for CForms
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]. 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 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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]. 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 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: Transparent and automatic AJAX support for CForms
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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
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 WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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
Sylvain Wallez wrote: 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
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]. 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 turns on the magic. I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/forms-samples/do-taskTree.flow 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 [EMAIL PROTECTED] 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
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]. 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 turns on the magic. I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/forms-samples/do-taskTree.flow 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Transparent and automatic AJAX support for CForms
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]. 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 turns on the magic. I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/forms-samples/do-taskTree.flow 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 [EMAIL PROTECTED] 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
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]. 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 turns on the magic. I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/forms-samples/do-taskTree.flow 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
