[x3d-public] X3dToJava.xslt CDATA

[Don Brutzman]

Interesting suggestion, thanks John.

It would seem that the XML export should be smart enough to add CDATA blocks, the setSourceCode method should be smart enough to strip them, and then the X3dToJava.xslt should ignore them as you suggest.

I will work on it and test.

On 12/10/2017 8:13 PM, John Carlson wrote:
> You may disagree with me, but I don’t think you should bury CDATA sections in Java with X3dToJava.xslt, especially since it generates nested CDATA sections in XML.
> 
> This fix should be in my patch already submitted.  Waiting for updates to www.web3d.org/x3d/stylesheets/java/examples/ <http://www.web3d.org/x3d/stylesheets/java/examples/>...  Or easy way to update the java in that folder. I already know how to do it the long way, looking for a ant target to update the Java file.
> 
> 
> If ant doesn’t update the java, then the bug generated doesn’t get fixed!
> 
> John
> 
>        .addChild(new ScriptObject("colorTypeConversionScript").setSourceCode(
> 
> "<![CDATA[" + "\n" +
> 
> "\n" +
> 
> "\n" +
> 
> "ecmascript:" + "\n" +
> 
> "\n" +
> 
> "function colorInput (eventValue) // Example source code" + "\n" +
> 
> "{" + "\n" +
> 
> "   colorsOutput = new MFColor(eventValue); // assigning value sends output event" + "\n" +
> 
> "// Browser.print('colorInput=' + eventValue + ', colorsOutput=' + colorsOutput + '\\n');" + "\n" +
> 
> "}" + "\n" + "]]>"
> 
> )
> 


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman