[Source] Extrusion diagnostics improved; how to get the DEF name of a node?

[Rex Melton]

An alternative suggestion.

In the xj3d browser app, there is a 
SceneTreeViewer. This is an example of walking the 
scenegraph and identifying nodes (and DEF names). 
It could be extended to provide a view of field 
data of selected nodes.

On 8/21/2012 11:54 PM, Alan Hudson wrote:
> on vacation till Sept 5th.  So very short reply.
>
> If you code something that provides the service 
> from the execution context level without adding 
> a per-node variable that's great.  I don't have 
> time to walk through the ways to implement this 
> and I personally don't need this functionality. 
>  Any map we have of def name - node should be 
> reversible in a slow walk of the map.
>
>
> On Tue, Aug 21, 2012 at 4:05 PM, Don Brutzman 
> <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>
>     On 8/21/2012 9:28 PM, Alan Hudson wrote:
>     > On 8/21/2012 11:47 AM, Richard Puk wrote:
>     >  Hi, Alan --
>     >>
>     >> Perhaps you can have your cake and eat it
>     too. Why not provide a run-time
>     >> switch that either enables the saving of
>     DEF names or disables it?
>
>     Very constructive suggestion, thanks Dick.
>
>     > you can't unallocate class variables at
>     runtime so if there is a slot for it in the
>     class then it consumes memory.
>
>     So maybe a similar approach might work?
>     - Empty strings consume very little memory.
>     - Empty hash tables consume very little memory.
>     - Some other on-demand approach perhaps?
>
>     I've asked for a testing-support mechanism and
>     - suggested several approaches,
>     - worked diligently to not break anything,
>     - asked a series of questions,
>     - emphasized testing for debugging broken
>     parts of Xj3D
>     - emphasized testing for making
>     architectural judgements
>     - remained polite and cooperative, looking
>     for common ground
>             in order to achieve greatest shared good
>
>     You guys have hinted that some mechanism
>     exists in X3DExecutionContext
>     but declined to explain how that might work.
>      I looked there to determine
>     what you might be saying, is it something
>     like lines 42-48:
>
>     >     public void
>     readableFieldChanged(X3DFieldEvent evt) {
>     >         System.out.println("Clicked!");
>     >         X3DExecutionContext
>     ec=myBrowser.getExecutionContext();
>     >         if(myRoute==null) {
>     >             System.out.println("Route added");
>     >
>     myRoute=ec.addRoute(ec.getNamedNode("OI"),"value_changed",
>     > ec.getNamedNode("greenBox"),"set_rotation");
>
>     That would only seem to work for retrieving
>     an X3DNode if DEF name
>     is known.  I'm asking how, or how best, to
>     do the opposite:  given
>     an X3DNode (presumably a 'this' reference),
>     how to retrieve the
>     corresponding DEF name?  Maybe I'm missing
>     something but I still don't
>     see that capability in there.
>
>     When one goes to X3DExecutionContext and
>     look up getNamedNode() to try to
>     decipher your pattern, one finds... an
>     interface definition with no method
>     bodies.  If one then goes to look up the
>     implementations of this interface,
>     there are four implementers/overriders:
>      BaseExecutionContext, SAIScene,
>     WorldScene, and X3DScene.  So you already
>     have multiple ways to override
>     the base classes depending on execution
>     context... which would be yet
>     another general approach to decide where to
>     put a utility method, with
>     at least four variants that exist.  Once
>     again, hat in hand, am asking
>     what guidance might experienced Xj3D
>     programmers provide about the best
>     way to accomplish this fundamental but
>     nontrivial task?
>
>     Instead you are both making forceful
>     arguments that appear to say:
>     - you don't and won't do it that in any way,
>     because you haven't
>     - no tests are needed to justify past
>     assertions, they are simply true
>       unless proven otherwise
>     - if i (or presumably anyone else) asks
>     again after "no," then they
>       don't understand open source (personal
>     attack?) or should just fork off
>       (discouraging common understanding, best
>     practices, community building?)
>
>
> if you don't want to listen to our experience on 
> something don't expect us to bend over backwards 
> to provide proven test cases to show that adding 
> variables to a class that is replicated 
> thousands to millions of times will add memory. 
>  My personal goals for Xj3D involve handling 
> large files efficiently so that's where I spend 
> my time.  If your use cases differs that's fine 
> but if they conflict then I'm going to put on my 
> project maintainers hat and say no.
>
>
>
> _______________________________________________
> Source mailing list
> Source at web3d.org
> http://web3d.org/mailman/listinfo/source_web3d.org