[x3d-public] X3dToJava.xslt -- "time zero" validation -- these files need run, and I haven't been able to generate working code yet either.

[Don Brutzman]

On 4/30/2017 4:42 AM, yottzumm at gmail.com wrote:
> Here are some Java files that X3dToJava.xslt generates, but which won’t run—and neither will my generated Java code.  I think we need some kind of strategy for this.  Got any suggestions?  Originals included.

yes a familiar issue that hasn't been resolved yet.

first off, they do all compile and run for me, without modification - hope that is the case for you too.

so the first problem seems to be that a lot of unnecessary warnings are printing out.

> We need to add the fieldValues after a ProtoInstance has been connected.  I suggest we store the proto instances in variables, add them to the scenegraph, then add their children after the rest of the scenegraph is built.

yes, that is a more classic approach.  it might be why HelloWorldProgram.java avoids this issue; mostly it is classically structured in the manner you suggest.

however that doesn't resolve the streamlined programming style of pipelined objects (Java 8), or the more general case (which is that programmers can do whatever they want).

> What do you think?
> 
> John

well, debugging shows that fieldValueObject is trying to validate values upon first instantiation, which is bad because it can't be corrected to anything else before it is created.

so (naturally) fieldValueObject reports it is not connected, e.g.

	ERROR_NOT_CONNECTED_TO_SCENE_GRAPH: fieldValue name='xtranslation' is not currently connected to SceneObject scene graph and thus getType() cannot be checked.

inspecting scene source indeed reveals that pattern of creation prior to connection, since instantions occur from inside out (bottom up):

    new ProtoDeclareObject().setName("twentyseven")
       .setProtoInterface(new ProtoInterfaceObject()
         .addField(new fieldObject().setAccessType("inputOutput").setName("ttranslation").setType("SFVec3f").setValue("0.0 0.0 0.0")))
       .setProtoBody(new ProtoBodyObject()
         .addChild(new TransformObject()
           .setIS(new ISObject()
             .setConnect(new connectObject().setNodeField("translation").setProtoField("ttranslation")))
           .addChild(new ProtoInstanceObject().setName("nine")
             .addFieldValue(new fieldValueObject().setName("ztranslation").setValue("0 0 0")))
           .addChild(new ProtoInstanceObject().setName("nine")
             .addFieldValue(new fieldValueObject().setName("ztranslation").setValue("0 0 2")))
           .addChild(new ProtoInstanceObject().setName("nine")
             .addFieldValue(new fieldValueObject().setName("ztranslation").setValue("0 0 -2"))))))

(confirming logic on order of operations: it is not possible to add an object that is still null to anything.)

so, now what to do about all these unhelpful premature warnings?

maybe we could push the validation up a level to the addFieldValue() level, but for this pathology i think that just kicks the can upstream....  the .addFieldValue method can't validate until its parent ProtoInstanceObject is created and connected.

also related: for X3D files, the rules say that the ProtoDeclare must appear prior to the ProtoInstance, a rule designed to maximize efficiency and loading speed.  we might be able to take advantage of that rule in these .x3d file conversions... but generally an SAI programmer might create fragments of the scene graph in any order, simply according to their program logic.  clearly we need a more robust approach.

so probably the necessary design approach is for X3DJSAIL to defer validation of cross-referenced prototype field types and values and instances until the scene graph is fully constructed, i.e. "time zero" of execution commencing.

will have to think a bit more regarding how to accomplish that in the code.  might have to wait until validate() method is called on X3DObject.  it might be further valuable if an X3DObject was able to perform self-validation regardless somehow.  learning about inherent errors is much more valuable than discovering mysterious run-time side effects.

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