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

[Justin Couch]

On 21/08/2012 3:17 PM, Don Brutzman wrote:
> I'm afraid that approach is simply insufficient for proper testing.

The problem is you're trying to test something that should not be 
tested. You're attacking the wrong problem. In this case, you're seeking 
a change in the language in order to support poor software engineering, 
which is always a bad thing to do. DEFs are a load-time only construct. 
After that they are stripped and thrown away. At run time, everything is 
handled via direct node references. For example, the ROUTE creation case 
you are talking about, the API call takes two node references and two 
field names. It doesn't take DEFs.

A mapping of DEFs is kept (See X3DExecutionContext), but only within the 
local context, and not as a property of the node. The only thing it can 
be used for is to find a node assuming you already know the name, which 
is consistent with the entire X3D ecosystem. It is not a programming 
API, it's a scene description and everything is organised around that 
core concept. You only get access to the things that you already know 
about and it doesn't break the information encapsulation.

> We must be able to test and diagnose Xj3D with nontrivial X3D content.
> You can't just guess which node (among dozens or hundreds) causes an
> Xj3D error when debugging unit-test content.

Simple basic software engineering - break the content up in to smaller 
pieces and only load the bits you want, or load the sub scene. Note also 
you're talking about unit tests here, which by definition are small 
pieces of content individually tested, not entire scenes. If the data 
modelling is correct, unit testing is trivial and also integration 
testing. As with all software engineering - if the code is difficult to 
test, then the abstraction is wrong and needs to be refactored until it 
is easy to test.

> Simple, typical approach:  add DEF string to base class for all nodes.
> Provide get/set accessor methods similar to other fields.

Except is isn't a field. It's a construction time piece of metadata. 
Like import/export names, it is not a property of the object, it's a 
label. You can't make it a property because then you'll break the rest 
of the X3D model - only one DEF of a given name within an execution 
context. If you had it as a node property, then it is trivially easy to 
break the X3D abstract model with this respect. That's why the SAI is 
designed the way it is - maintain consistency with the X3D abstract model.

-- 
Justin Couch                         http://www.vlc.com.au/justin/
3D Java Graphics Information                    http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------