: : DOMUtils.getAttributeWithInheritance instead. My one scenario I came
: : across where I wanted some context passed down was "fieldName" and this
: : is handled simply by leaf nodes walking up the w3c.dom.Node tree until
: : you find an Element with this attribute set.
:
: Hmm, i can see how that would work in some cases, but it's not very
: general purpose. Builders deep in the tree can "look up" at attributes
: higher in the tree, but that assumes the state info they want is already
: in the XML Elements (allthough i suppose builders higher up could
: mutate the attributes on their Element for discovery by lower level
: builders ... but that seems sketchy).
:
: It also doesn't address the problem of passing state up the tree ... which
: may be a less common case, but it still seems important to support it.
I should have thought about this more before i replied. Two things
have occured to me in the last 30 minutes...
1) the idea i had once upon a time for maintaining stack frames of
"state" would have required builders that wanted to propogate state up
from their children to do so explicitly -- there's no reason why the same
thing couldn't be done by checking the attribute values of their child
Elements and setting them on their own Element before returning. So
yeah ... using attributes to pass state up/down would probably work in all
the cases i can think of..
....BUT...
it still seems sketchy to me to use attributes, because it could be
important to be able to tell the difference between "true" attributes
from the XML and "state" attributes passed up/down from other builders.
2) In java 1.5, org.w3c.dom.Node has setUserData/getUserData methods
specifically for the purpose of letting you annotate nodes as you move
arround the tree.
So yeah ... that's something to think about.
Perhaps attribute namespaces could be used to distinguish genuine
attributes from state information ... of course that raises a whole new
question about wether the builderfactories should support namespaces when
registering builders.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
