[x3d-public] X3DJSAIL, possible bug in JS generation (solving with a stylesheet?) future of various stylesheets, possible merging

[John Carlson]

What is the likelihood of resurrecting either X3dToES5.xslt or X3dToES6.xslt to handle this?  This is likely a severe problem with X3DJSONLD in general, but not sure which serializers it might affect yet.  It would probably match X3DJSAIL architecture a lot better if we used a stylesheet, but I’m not in charge of Don’s time, and I think it might be better spent creating a X3dToPython.xslt (or X3DPythonSAIL that can use pipelining—either with PyJNIUs or without).

What’s the priority for generating JavaScript from X3DJSAIL vis a vi Python from X3DJSAIL?

I might get in to the stylesheet business again if Don’s busy with X3dToPython.xslt, and I would be probably the last person to touch the JavaScript stylesheets.

In otherwords, I’m pretty much ready to bail on X3DJSONLD Serializers and go with stylesheets (except perhaps for the web and DOM2JSONSerializer.js)

Or perhaps I should look at the ProtoBody in the serializer? For the actual child?  What if it’s a switch?


Should we be looking to generate the X3dTo*.xslt from a more unified source or two? IDK, Don’s probably the best one to comment.  Perhaps that work is already done?

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Tuesday, October 16, 2018 9:21 PM
To: X3D Graphics public mailing list
Subject: RE: X3DJSAIL, possible bug in JS generation

I confirmed that the override is there, and it is set to setMaterial.  So there’s no current way to addShaders, since I believe that setMaterial is the most common containerField.  How does X3dToJava.xslt handle this choice for containerFields?  We can discuss this at the meeting tomorrow at 2pm PST, but this is likely a widespread problem with mapToMethod*.js

The parent element is Appearance, and the ProtoInstance is the child.  How can we automatically choose either setMaterial or addShaders?  Do I need to look at the ProtoBody?

Does this have something to do with ExternProtoDeclare validation?  Would X3DUOM resolve it if I just looked closer (and put it in mapToMethod.js which is autogenerated?)

Seems like we’re getting to some really gnarly bugs which require looking at the scenegraph or extended scenegraph in more detail.

Thanks,

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Tuesday, October 16, 2018 9:01 PM
To: X3D Graphics public mailing list
Subject: X3DJSAIL, possible bug in JS generation

It looks like the JS generation (JavaScriptSerializer.js) may have an issue with addShaders being
generated for ProtoInstanceObject’s. This happens when mapToMethod2.js has no override for the ProtoInstance child I think, but
I will check soon.

Here is the JS code:

coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/www.web3d.org/x3d/stylesheets/java/nashorn/examples
$ grep addShaders *
HelloWorldProgramOutput.Nashorn.js:            .addShaders(new ProgramShaderObject().setDEF("TestShader1")
HelloWorldProgramOutput.Nashorn.js:            .addShaders(new ComposedShaderObject().setDEF("TestShader4")

Here is the original Java code:


HelloWorldProgram.java:                        .addShaders(new ProgramShaderObject("TestShader1")
HelloWorldProgram.java:                        .addShaders(new ProtoInstanceObject("ShaderProto","TestShader3"))
HelloWorldProgram.java:                        .addShaders(new ComposedShaderObject("TestShader4")


Here is the generated Java code:

HelloWorldProgramOutput.java:        .addShaders(new ProgramShaderObject()
HelloWorldProgramOutput.java:        .addShaders(new ProtoInstanceObject("ShaderProto", "TestShader3"))
HelloWorldProgramOutput.java:        .addShaders(new ComposedShaderObject()


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181016/256f4072/attachment-0001.html>