[x3d-public] X3DJSAIL. adding a field value to a ProtoInstanceObject.
Don Brutzman
brutzman at nps.edu
Sat Feb 25 23:06:48 PST 2017
On 2/25/2017 7:49 PM, John Carlson wrote:
> I am fairly sure you are suggesting we generate attributes first.
Correct. Recommended order of construction:
a. attributes (at a minimum DEF USE and name, since those are used by internal error checks)
b. parent element
c. other attributes, if any
d. field, fieldValue
e. IS/connect
f.child SFNode/MFNode fields
> On Feb 25, 2017 10:47 PM, "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>
> I could use a more declarative form, but that might require more chained methods in X3DJSAIL. I basically have a choice to produce children first or attributes first in the java serializers. The exception for that is container fields if we want to handle them specially for the intermediate XML.
for X3DJSAIL you should not handle containerFields at all, they are taken care of for you (containerField simply equals field name).
> Are there cases where we have to deviate from attributes first or children first? Is the deviation documented in the object model? Is the deviation documented someplace we can generate code from?
i think the order above takes care of things.
IS/connect can go last, but must follow field declarations (at least in XML encoding). I prefer IS/connect definitions up near attributes for clarity.
good luck sorting things out!
> On Feb 25, 2017 8:11 PM, "Don Brutzman" <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>
> Your attached source (thank you for that) is complaining because the parent ProtoInstance is not yet connected to scene graph, and so, as written, adding a fieldValue cannot be checked as valid when building that combination of elements.
>
> Interestingly it is not a "compile time" error but rather a "load time" error when the java program is first launched. Perhaps different than other "run time" errors?
>
> Exploration follows.
>
> We could disable this exception error but then when the code problems unavoidably occur, any diagnostic is triggered far from the point of origin of the problem. That can become much harder to debug. Allowing problematic code that might (or might not) get fixed by later code is pretty dangerous, even "wishful thinking" perhaps.
>
> Am thinking it is best to "make it hard to create erroneous X3D". Avoiding error-prone technique seems worth pursuing if possible.
>
> Towards making it easier, improved verbosity of the exception response a little:
>
> Exception in thread "main" org.web3d.x3d.sai.InvalidFieldException:
> Illegal addFieldValue() invocation for ProtoInstanceObject name='' fieldValue name='StbdRunningLightPosition', newFieldValue.validation() failure:
> ErrorNotConncectedToSceneGraph, fieldValue is not connected to a scene graph and thus getType() cannot be checked.
>
> To avoid the error in your autogenerated source RunningLightsExample.java, add the parent ProtoDeclare to the parent node before adding fields. In other words, move
>
> line 337
> ProtoInstance0_2_14_0_0.setName("RunningLights");
>
> and line 338
> Transform0_2_14_0.addChildren(ProtoInstance0_2_14_0_0);
>
> up to immediately follow the declaration on line 264, resulting in
>
> ProtoInstanceObject ProtoInstance0_2_14_0_0 = new ProtoInstanceObject();
> ProtoInstance0_2_14_0_0.setName("RunningLights"); // *this line got moved up*
> Transform0_2_14_0.addChildren(ProtoInstance0_2_14_0_0); // *this line got moved up*
>
> That fixes the run-time error you saw. However, it also just pushes the error around in your program, since, other things in your source are still not connected in the right order.
>
> It is possible to reshuffle the entire program ordering to avoid such problems. It is certainly good practice to build code that works as fully as possible as you go along, and that is why the library is trying to validate wherever feasible when building a scene graph.
>
> However am wondering if it is now starting to feel pretty draconian... perhaps a programmer might not be able to build prototypes within a scene graph in perfect order if the structure is being figured out at run time.
>
> That leads to thinking it might be OK to change X3DJSAIL to accept this particular validation notification, but nevertheless adding a warning that validate() validation is needed... Perhaps even a relaxed or strict mode will be called for???
>
> ... but then here we go right down the slippery slope, enabling creation of error-prone code. Failing unexpectedly at some future "run time" instead of "compile time" or even "load time" is really worth preventing whenever possible. Ignoring a problem early (i.e. avoiding an error-check early) only defers such errors to later.
>
> Even worse, if autogenerated examples are creating code that is difficult to debug, then problematic practices can propagate even farther.
>
> Of note, if an X3D scene author created ProtoDeclare ProtoInstance etc. out of order, the scene would fail validation. Ordering is important for certain X3D nodes, that permits single-pass loading of a large scene. It also shows that careful ordering is possible when creating any scene.
>
> Of peripheral note: Douglas Crockford's exceedingly strict approaches in JSON, and strong recommendations for strictness in _Javascript the Good Parts_ completely turned around the reliability of javascript programming. Strong evidence of the benefits of coding.
>
> Predecessor concept is the Postel's Law:
>
> https://en.wikipedia.org/wiki/Robustness_principle <https://en.wikipedia.org/wiki/Robustness_principle>
> ===============
> In computing, the robustness principle is a general design guideline for software:
>
> Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").
>
> The principle is also known as Postel's law, after internet pioneer Jon Postel, who wrote in an early specification of the Transmission Control Protocol that:
>
> TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
> ===============
>
> Adapting these concepts here: OK to be liberal about unambiguous mistakes (quoting etc.) when importing an X3D file from someplace else, but be as strict as possible when creating a scene graph that gets used by someone else.
>
> So, upon consideration, recommended next step: please look at changing your prototype, script and shader instantiation patterns to match the order of connection shown above, and also found in HelloWorldExample.java protodeclare examples, for best reliability.
>
> Am thinking that keeping X3DJSAIL as strict as practically possible will remain the best approach. Am also expecting that, over long term, we will be glad we did so.
>
> Let's keep looking closely at this, continued questions/examples/improvements welcome. Thanks John.
>
>
> On 2/21/2017 3:22 PM, yottzumm at gmail.com <mailto:yottzumm at gmail.com> wrote:
>
> I’m connecting it to the scenegraph??? You mean the interface or the IS? Looks like validate is called before the field value is added.
>
>
>
> John
>
>
>
> www_web3d_org/x3d/content/examples/Savage/ShipsMilitary/RunningLights/RunningLightsExample.java
>
> Exception in thread "main" org.web3d.x3d.sai.InvalidFieldException: Illegal addFieldValue() invocation, invalid newFieldValue.validation(): fieldValue is not connected to a scene graph and cannot be checked.
>
> fieldValue is not connected to a scene graph and cannot be checked.
>
>
>
> at org.web3d.x3d.jsail.Core.ProtoInstanceObject.addFieldValue(ProtoInstanceObject.java:972)
>
> at www_web3d_org.x3d.content.examples.Savage.ShipsMilitary.RunningLights.RunningLightsExample.main(RunningLightsExample.java:268)
>
>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 <tel:%2B1.831.656.2149>
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
>
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
More information about the x3d-public
mailing list