FireDragon Posted April 26, 2006 Share Posted April 26, 2006 The problem is the following:"<![CDATA[" && "]]>" , where "&&" is been parsed by XML parser and converted into: &&. In result CDATA code is been brocken. Link to comment Share on other sites More sharing options...
boen_robot Posted April 26, 2006 Share Posted April 26, 2006 (edited) CDATA displays what you show as it is. That's why JavaScripts in XML files are enclosed by CDATA sections- you keep the exact same characters, therefore use the script and you don't interfere with the parser.Show the full "broken" code please. I don't see a problem.[edit] A closer examination... When you write something like "<hr />" inside an XML element, it's treated as an XML element. Using "<hr />" instead returns the charaters "<" and ">" in the place of the entity codes, so therefore you get litteral the litteral text "<hr />". Using "<![CDATA[<hr />]]>" means that the parser shows litterly what's inside the CDATA section, which in our case is again the plain text <hr />. However, that doesn't mean that the special characters in CDATA were transformed to entites. They were just displayed on the screen as one whole (copy and paste or so to say) the same way as "<![CDATA[<hr />]]>" would have resulted in the litteral text "<hr />" .[/edit] Edited April 26, 2006 by boen_robot Link to comment Share on other sites More sharing options...
FireDragon Posted April 26, 2006 Author Share Posted April 26, 2006 CDATA displays what you show as it is. That's why JavaScripts in XML files are enclosed by CDATA sections- you keep the exact same characters, therefore use the script and you don't interfere with the parser.Show the full "broken" code please. I don't see a problem.[edit] A closer examination... When you write something like "<hr />" inside an XML element, it's treated as an XML element. Using "<hr />" instead returns the charaters "<" and ">" in the place of the entity codes, so therefore you get litteral the litteral text "<hr />". Using "<![CDATA[<hr />]]>" means that the parser shows litterly what's inside the CDATA section, which in our case is again the plain text <hr />. However, that doesn't mean that the special characters in CDATA were transformed to entites. They were just displayed on the screen as one whole (copy and paste or so to say) the same way as "<![CDATA[<hr />]]>" would have resulted in the litteral text "<hr />" .[/edit]<{POST_SNAPBACK}> <![CDATA[// other parameters displaywhenempty="" valuewhenempty=-1 displaywhennotempty="-select-" valuewhennotempty=0function change(currentbox) { numb = currentbox.id.split("_"); currentbox = numb[1]; i=parseInt(currentbox)+1// I empty all combo boxes following the current one while ((eval("typeof(document.getElementById(\"combo_"+i+"\"))!='undefined'")) && (document.getElementById("combo_"+i)!=null)) { son = document.getElementById("combo_"+i); // I empty all options except the first one (it isn't allowed) for (m=son.options.length-1;m>0;m--) son.options[m]=null; // I reset the first option son.options[0]=new Option(displaywhenempty,valuewhenempty) i=i+1 }// now I create the string with the "base" name ("stringa"), ie. "data_1_0"// to which I'll add _0,_1,_2,_3 etc to obtain the name of the combo box to fill stringa='data' i=0 while ((eval("typeof(document.getElementById(\"combo_"+i+"\"))!='undefined'")) && (document.getElementById("combo_"+i)!=null)) { eval("stringa=stringa+'_'+document.getElementById(\"combo_"+i+"\").selectedIndex") if (i==currentbox) break; i=i+1 }// filling the "son" combo (if exists) following=parseInt(currentbox)+1 if ((eval("typeof(document.getElementById(\"combo_"+following+"\"))!='undefined'")) && (document.getElementById("combo_"+following)!=null)) { son = document.getElementById("combo_"+following); stringa=stringa+"_" i=0 while ((eval("typeof("+stringa+i+")!='undefined'")) || (i==0)) { // if there are no options, I empty the first option of the "son" combo // otherwise I put "-select-" in it if ((i==0) && eval("typeof("+stringa+"0)=='undefined'")) if (eval("typeof("+stringa+"1)=='undefined'")) eval("son.options[0]=new Option(displaywhenempty,valuewhenempty)") else eval("son.options[0]=new Option(displaywhennotempty,valuewhennotempty)") else eval("son.options["+i+"]=new Option("+stringa+i+".text,"+stringa+i+".value)") i=i+1 } //son.focus() i=1 combostatus='' cstatus=stringa.split("_") while (cstatus[i]!=null) { combostatus=combostatus+cstatus[i] i=i+1 } return combostatus; }}]]> Where every "&" was converted into & intro the representing HTML Link to comment Share on other sites More sharing options...
boen_robot Posted April 26, 2006 Share Posted April 26, 2006 The code you have provided is way too complex for my kind of JavaScript experience. Nevertheless, I was able to made some test with My own kind of an example...If this JavaScript is in XHTML file, keep it without CDATA sections. Even if in truth is suppose to be with CDATA, I can't think of a way around this odd (in my opinion) behaviour.If it's in XML file, use the CDATA around the script but inside the tag. If you use XSLT to transform that XML, simply use <xsl:value-of select="XPath to the JavaSciprt" disable-output-escaping="yes" /> (not working in Firefox... hopefully only "yet", not forever). Link to comment Share on other sites More sharing options...
FireDragon Posted April 26, 2006 Author Share Posted April 26, 2006 I modified the JavaScript code so now there are no "&" and it's working properly!But you are right that behaviour is "strange".And as we say: -Kaji baba:"Thank you"! -"Thank you!" Thanks anyway. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now