EntityReference models the XML &entityname; syntax, when used for
entities defined by the DOM. Entities hardcoded into XML, such as
character entities, should instead have been translated into text
by the code which generated the DOM tree.
An XML processor has the alternative of fully expanding Entities
into the normal document tree. If it does so, no EntityReference nodes
will appear.
Similarly, non-validating XML processors are not required to read
or process entity declarations made in the external subset or
declared in external parameter entities. Hence, some applications
may not make the replacement value available for Parsed Entities
of these types.
EntityReference behaves as a read-only node, and the children of
the EntityReference (which reflect those of the Entity, and should
also be read-only) give its replacement value, if any. They are
supposed to automagically stay in synch if the DocumentType is
updated with new values for the Entity.
The defined behavior makes efficient storage difficult for the DOM
implementor. We can't just look aside to the Entity's definition
in the DocumentType since those nodes have the wrong parent (unless
we can come up with a clever "imaginary parent" mechanism). We
must at least appear to clone those children... which raises the
issue of keeping the reference synchronized with its parent.
This leads me back to the "cached image of centrally defined data"
solution, much as I dislike it.
For now I have decided, since REC-DOM-Level-1-19980818 doesn't
cover this in much detail, that synchronization doesn't have to be
considered while the user is deep in the tree. That is, if you're
looking within one of the EntityReferennce's children and the Entity
changes, you won't be informed; instead, you will continue to access
the same object -- which may or may not still be part of the tree.
This is the same behavior that obtains elsewhere in the DOM if the
subtree you're looking at is deleted from its parent, so it's
acceptable here. (If it really bothers folks, we could set things
up so deleted subtrees are walked and marked invalid, but that's
not part of the DOM's defined behavior.)
As a result, only the EntityReference itself has to be aware of
changes in the Entity. And it can take advantage of the same
structure-change-monitoring code I implemented to support
DeepNodeList.
getBaseURI
public String getBaseURI()
Returns the absolute base URI of this node or null if the implementation
wasn't able to obtain an absolute URI. Note: If the URI is malformed, a
null is returned.
- getBaseURI in interface NodeImpl
- The absolute base URI of this node or null.
getEntityRefValue
protected String getEntityRefValue()
NON-DOM: compute string representation of the entity reference.
This method is used to retrieve a string value for an attribute node that has child nodes.
- String representing a value of this entity ref. or
null if any node other than EntityReference, Text is encountered
during computation
getNodeName
public String getNodeName()
Returns the name of the entity referenced
- getNodeName in interface NodeImpl
getNodeType
public short getNodeType()
A short integer indicating what type of node this is. The named
constants for this value are defined in the org.w3c.dom.Node interface.
- getNodeType in interface NodeImpl
setBaseURI
public void setBaseURI(String uri)
NON-DOM: set base uri
setReadOnly
public void setReadOnly(boolean readOnly,
boolean deep)
NON-DOM: sets the node and its children value.
Note: make sure that entity reference and its kids could be set readonly.
- setReadOnly in interface ParentNode
synchronizeChildren
protected void synchronizeChildren()
EntityReference's children are a reflection of those defined in the
named Entity. This method creates them if they haven't been created yet.
This doesn't support editing the Entity though, since this only called
once for all.
- synchronizeChildren in interface ParentNode