Hi, I have a problem with Scriptaculous and SeasideAsync. I have a liveCalback ( on a select tag ) when gets evaluated it shows a SUAutocompleterTest instance. Then when I select an item, all components are gone except the SUAutocompleterTest. On the other hand, if I switch/replace the SUAutocompleterTest and render another component it works fine.
I´ve attached an example to reproduce the behavior. Any ideas? aRenderer select list: #(one two); selected: #one; callback:[:f | ]; liveCallback: [:anObject :h | h div id: 'xxlive';with: [ anObject = #two ifTrue: [ h render: component "a SUAutocompleterTest instance"]] ]. aRenderer div id: 'xxlive';with: '' - I add SULibrary and WAAsyncScripts libraries - I'm using Squeak3.8/Seaside2.7a1-mb.155/SeasideAsync-mb.48. Regards. Juan Matias. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Hi, I have a problem with Scriptaculous and SeasideAsync. I have a
> liveCalback ( on a select tag ) when gets evaluated it shows a > SUAutocompleterTest instance. Then when I select an item, all components are > gone except the SUAutocompleterTest. On the other hand, if I switch/replace > the SUAutocompleterTest and render another component it works fine. > I´ve attached an example to reproduce the behavior. > Any ideas? > > aRenderer select > list: #(one two); > selected: #one; > callback:[:f | ]; > liveCallback: [:anObject :h | h div id: 'xxlive';with: [ > anObject = #two ifTrue: [ h render: > component "a SUAutocompleterTest instance"]] > ]. > aRenderer div id: 'xxlive';with: '' I doubt that SeasideAsync and Scriptaculous work together that close. I would try to use Scriptaculous **xor** SeasideAsync. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Burella Juan M.
> > - I add SULibrary and WAAsyncScripts libraries > - I'm using Squeak3.8/Seaside2.7a1-mb.155/SeasideAsync-mb.48. > Hi Juan, Before giving up, you may want to give it a try with the latest SeasideAsync (53). It has some interesting enhancements that may help in your case. Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Burella Juan M.
> > - I add SULibrary and WAAsyncScripts libraries > - I'm using Squeak3.8/Seaside2.7a1-mb.155/SeasideAsync-mb.48. > Hi Juan, You may want to give it a try with the latest SeasideAsync (53). It has some interesting enhancements that may help in your case. Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Michel
I've tested it in Seaside2.7a1-dc.128/SeasideAsync-mb.54 but doesn't work fine, the problem persist. What enhacements should I look for in order to fix it? thanks for your answer
On 11/18/06, Michel Bany <[hidden email]> wrote:
_______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 20 Nov 2006, at 16:49 , Burella Juan M. wrote: > Hi Michel > I've tested it in Seaside2.7a1-dc.128/SeasideAsync-mb.54 but > doesn't work fine, the problem persist. What enhacements should I > look for in order to fix it? > thanks for your answer > Looks like a problem in Seaside and/or Scriptaculous. The SeasideAsync javascripts use the XML parser supplied by the XMLHttpRequest object. Therefore the response from the live callback must be well-formed XML, otherwise, it cannot be parsed (at least in some browsers). When the response from the live callback includes some Scriptaculous stuff, then it is not well-formed, because it contains some ampersands. Since Seaside generates the script tags with #html: rather than #text: there is no encoding of ampersands into entities. This is not well- formed XML and cannot be parsed, at least by the Firefox XML parser. I do not know what should be fixed, Seaside or Scriptaculous. Lukas, any idea ? Meanwhile, you can try the following fix to SUAjax : parameters ^ (self options at: 'parameters' ifAbsentPut: [ SUJoin join: OrderedCollection new with: '&' ]) collection HTH, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> I do not know what should be fixed, Seaside or Scriptaculous.
> > Lukas, any idea ? > > Meanwhile, you can try the following fix to SUAjax : > > parameters > ^ (self options at: 'parameters' ifAbsentPut: > [ SUJoin join: OrderedCollection new with: '&' ]) collection Don't try this, it breaks Scriptaculous. The encoding works fine as long as you only attach your scripts to element events, such as #onClick:, #onChange:, etc. The problem is that the method #with: in WAScriptTag was implemented in a very strange way, it bypassing the encoding and caused the observed problem. The missing thing was the <![CDATA[ ... ]]> tag. Unfortunately the same bug is duplicated in at least 4 places trough out the framework. The latest version of 2.7 fixes these problems. I don't know the effect of this change, it might well be that older browser have their problems. I tested it on Safari and FireFox. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2006/11/21, Lukas Renggli <[hidden email]>:
> > I do not know what should be fixed, Seaside or Scriptaculous. > > > > Lukas, any idea ? > > > > Meanwhile, you can try the following fix to SUAjax : > > > > parameters > > ^ (self options at: 'parameters' ifAbsentPut: > > [ SUJoin join: OrderedCollection new with: '&' ]) collection > > Don't try this, it breaks Scriptaculous. The encoding works fine as > long as you only attach your scripts to element events, such as > #onClick:, #onChange:, etc. > > The problem is that the method #with: in WAScriptTag was implemented > in a very strange way, it bypassing the encoding and caused the > observed problem. The missing thing was the <![CDATA[ ... ]]> tag. > Unfortunately the same bug is duplicated in at least 4 places trough > out the framework. The latest version of 2.7 fixes these problems. I > don't know the effect of this change, it might well be that older > browser have their problems. I tested it on Safari and FireFox. Don't use CDATA ffs. It does simply not work which is why we don't do it for text. We encode text properly so let's also encode scripts properly. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Don't use CDATA ffs. It does simply not work which is why we don't do
> it for text. We encode text properly so let's also encode scripts > properly. Unfortunately encoding does not work, this was what I first tried of course. CDATA works and validates in the browser I tested. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
2006/11/21, Lukas Renggli <[hidden email]>:
> > I do not know what should be fixed, Seaside or Scriptaculous. > > > > Lukas, any idea ? > > > > Meanwhile, you can try the following fix to SUAjax : > > > > parameters > > ^ (self options at: 'parameters' ifAbsentPut: > > [ SUJoin join: OrderedCollection new with: '&' > ]) collection > > Don't try this, it breaks Scriptaculous. The encoding works fine as > long as you only attach your scripts to element events, such as > #onClick:, #onChange:, etc. > > The problem is that the method #with: in WAScriptTag was implemented > in a very strange way, it bypassing the encoding and caused the > observed problem. The missing thing was the <![CDATA[ ... ]]> tag. > Unfortunately the same bug is duplicated in at least 4 places trough > out the framework. The latest version of 2.7 fixes these problems. I > don't know the effect of this change, it might well be that older > browser have their problems. I tested it on Safari and FireFox. Wouldn't the same behavior also apply to styles? Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Wouldn't the same behavior also apply to styles?
I don't know, but that is rarely used in Seaside anyway. The only thing I found out was that a script that has the & encoded as & doesn't work within a <script>, but does within an attribute value. JavaScript code only works in a <script> when the contents is not encoded, but this turns the XHTML invalid if the contents is not within a CDATA construct. The CDATA construct should not harm any browser that does not understand it, so what is your aversion against it except that you don't like it? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Burella Juan M.
BTW, scriptaculous docs actually suggest wrapping all scripts in CDATA to avoid issues with using < and > inside, so its can't be *that* much of a problem. I recall seeing the suggestion other times too. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
2006/11/21, Lukas Renggli <[hidden email]>:
> > Wouldn't the same behavior also apply to styles? > > I don't know, but that is rarely used in Seaside anyway. > > The only thing I found out was that a script that has the & encoded as > & doesn't work within a <script>, This is really strange. > but does within an attribute > value. JavaScript code only works in a <script> when the contents is > not encoded, but this turns the XHTML invalid if the contents is not > within a CDATA construct. The CDATA construct should not harm any > browser that does not understand it, so what is your aversion against > it except that you don't like it? CDATA is not part of HTML. It's part of XML and we serve as text/html which means it gets treated as HTML. It's just plain wrong. Second, it breaks as soon as somewhere in a script is ']]>' lets say for XML parsing or whatever. For the person this happens this will mean real pain. It's not a solution, it just appears to works in some cases. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Burella Juan M.
On 20 Nov 2006, at 16:49 , Burella Juan M. wrote: > Hi Michel > I've tested it in Seaside2.7a1-dc.128/SeasideAsync-mb.54 but > doesn't work fine, the problem persist. What enhacements should I > look for in order to fix it? > thanks for your answer Now that Lukas has enhanced Seaside and Scriptaculous to provide proper encoding for the script elements, I also enhanced SeasideAsync in the same way. You may want to try again with the latest combination - Seaside2.7a1-lr.131 - Scriptaculous-lr.154 - SeasideAsync-mb.56 I tried it with your code and got the autocompleter to display within the rest of the page, fully functionnal. Best luck, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
This article seems to say that CDATA should be used in XHTML for javascript. XHTML is what is targeted by Seaside anyway. Also, I believe that the w3c html 4 spec mentions CDATA. Finally, I found out that the mistake was also in SeasideAsync itself which was not properly encoding the scripts produced by Scriptaculous. So I changed SeasideAsync to enclose the scripts within a CDATA without the comment constructs. The comment construct is not used because SeasideAsync callbacks respond with a 100% well-formed XML document (including the <?xml . . . ?> header) and the CDATA cannot be parsed when it is polluted by the comment construct. My initial tests indicate that Scriptaculous scripts can now be generated from within SeasideAsync callbacks. Who is going to try a SeasideAsync live request from within a Scriptaculous callback ? How deep can we nest the SeasideAsync and Scriptaculous callbacks ? Cheers, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
> > The only thing I found out was that a script that has the & encoded as
> > & doesn't work within a <script>, > > This is really strange. Yes, agreed. Feel free to try it out yourself. > > but does within an attribute > > value. JavaScript code only works in a <script> when the contents is > > not encoded, but this turns the XHTML invalid if the contents is not > > within a CDATA construct. The CDATA construct should not harm any > > browser that does not understand it, so what is your aversion against > > it except that you don't like it? > > CDATA is not part of HTML. It's part of XML and we serve as text/html > which means it gets treated as HTML. It's just plain wrong. So what? Luckily there is a Javascript comment around the CDATA so non-xml parsers still handle it properly. Maybe then the mime-type of responses should be changed to text/xml, this would be more consistent anyway? > Second, it breaks as soon as somewhere in a script is ']]>' lets say > for XML parsing or whatever. For the person this happens this will > mean real pain. It's not a solution, it just appears to works in some > cases. Please find a better solution that works instead of only complaining. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2006/11/22, Lukas Renggli <[hidden email]>:
> > > The only thing I found out was that a script that has the & encoded as > > > & doesn't work within a <script>, > > > > This is really strange. > > Yes, agreed. Feel free to try it out yourself. If it wasn't you I wouldn't believe it until I tried it. Digging deeper there is CDATA and PCDATA in html :( Not to be confused with <![CDATA[ > > > but does within an attribute > > > value. JavaScript code only works in a <script> when the contents is > > > not encoded, but this turns the XHTML invalid if the contents is not > > > within a CDATA construct. The CDATA construct should not harm any > > > browser that does not understand it, so what is your aversion against > > > it except that you don't like it? > > > > CDATA is not part of HTML. It's part of XML and we serve as text/html > > which means it gets treated as HTML. It's just plain wrong. > > So what? Luckily there is a Javascript comment around the CDATA so > non-xml parsers still handle it properly. Ah, I missed this point completly. This changes a lot. Acutally this addresses everything but a script that contains ']]>' > Maybe then the mime-type of > responses should be changed to text/xml, this would be more consistent > anyway? > > > Second, it breaks as soon as somewhere in a script is ']]>' lets say > > for XML parsing or whatever. For the person this happens this will > > mean real pain. It's not a solution, it just appears to works in some > > cases. > > Please find a better solution that works instead of only complaining. Yeah I know. And if I have a problem with the VM I should just stfu and fix it. All I can think of right now would break on html parsers. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>
Yes, that special thing of encoding will be tackled as soon as someone
> > > > but does within an attribute > > > > value. JavaScript code only works in a <script> when the contents is > > > > not encoded, but this turns the XHTML invalid if the contents is not > > > > within a CDATA construct. The CDATA construct should not harm any > > > > browser that does not understand it, so what is your aversion against > > > > it except that you don't like it? > > > > > > CDATA is not part of HTML. It's part of XML and we serve as text/html > > > which means it gets treated as HTML. It's just plain wrong. > > > > So what? Luckily there is a Javascript comment around the CDATA so > > non-xml parsers still handle it properly. > > Ah, I missed this point completly. This changes a lot. Acutally this > addresses everything but a script that contains ']]>' is complaining. Different encoding within different parts of the resulting page is something that is neglected right now, you can only choose between no-encoding or HTML encoding. Looks like a project to properly implement the different encodings for URLs, Scripts, CSS, Attributes, etc. The attached script is a good start to play around with these encoding issues (in the context of scripts for now). It should dispay 3 alert boxes with the string "done ...", should not raise warnings/errors and should validate. > All I can think of right now would break on html parsers. Yeah, text/xml breaks almost all applications as Web browsers get very picky and display all kinds of warnings and errors. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside WAScriptEncodingTest.st (1K) Download Attachment |
In reply to this post by Michel Bany
It worked fine.
Thanks very much for all answers. Juan Matías. On 11/22/06, Michel Bany <[hidden email]> wrote:
_______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 22 Nov 2006, at 16:08 , Burella Juan M. wrote: > It worked fine. > Thanks very much for all answers. > > Juan Matías. Thanks for the feedback. Be aware that there are some new issues in using SeasideAsync because of the new CDATA encoding for javascripts. This is being looked at. Cheers, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |