gnu.xml.dom
Class DomAttr
java.lang.Object
|
+--gnu.xml.dom.DomNode
|
+--gnu.xml.dom.DomNsNode
|
+--gnu.xml.dom.DomAttr
All Implemented Interfaces:
Attr, Node, NodeList, EventTarget, DocumentEvent, Cloneable
"Attr" implementation. In DOM, attributes cost quite a lot of
memory because their values are complex structures rather than just
simple strings. To reduce your costs, avoid having more than one
child of an attribute; stick to a single Text node child, and ignore
even that by using the attribute's "nodeValue" property.
As a bit of general advice, only look at attribute modification
events through the DOMAttrModified event (sent to the associated
element). Implementations are not guaranteed to report other events
in the same order, so you're very likely to write nonportable code if
you monitor events at the "children of Attr" level.
At this writing, not all attribute modifications will cause the
DOMAttrModified event to be triggered ... only the ones using the string
methods (setNodeValue, setValue, and Element.setAttribute) to modify
those values. That is, if you manipulate those children directly,
elements won't get notified that attribute values have changed.
The natural fix for that will report other modifications, but won't
be able to expose "previous" attribute value; it'll need to be cached
or something (at which point why bother using child nodes).
You are strongly advised not to use "children" of any attribute
nodes you work with.
Author:DomAttr
protected DomAttr(org.w3c.dom.Document owner, java.lang.String namespaceURI, java.lang.String name)
Constructs an Attr node associated with the specified document.
The "specified" flag is initialized to true, since this DOM has
no current "back door" mechanisms to manage default values so
that every value must effectively be "specified".
This constructor should only be invoked by a Document as part of
its createAttribute functionality, or through a subclass which is
similarly used in a "Sub-DOM" style layer.
Parameters:
clone
public Object clone()
Shallow clone of the attribute, breaking all ties with any
elements.
getName
public final String getName()
DOM L1
Returns the attribute name (same as getNodeName)
getNodeType
public final short getNodeType()
DOM L1
Returns the constant ATTRIBUTE_NODE.
getNodeValue
public String getNodeValue()
DOM L1
Returns the attribute value, with character and entity
references substituted.
NOTE: entity refs as children aren't currently handled.
getOwnerElement
public final Element getOwnerElement()
DOM L2
Returns the element with which this attribute is associated.
getSpecified
public final boolean getSpecified()
DOM L1
Returns true if a parser reported this was in the source text.
getValue
public final String getValue()
DOM L1
Returns the value of the attribute as a non-null string; same
as getNodeValue.
NOTE: entity refs as children aren't currently handled.
setNodeValue
public void setNodeValue(java.lang.String value)
DOM L1
Assigns the attribute value; using this API, no entity or
character references will exist.
Causes a DOMAttrModified mutation event to be sent.
Parameters:
setOwnerElement
public final void setOwnerElement(org.w3c.dom.Element e)
Records the element with which this attribute is associated.
Parameters:
setSpecified
public final void setSpecified(boolean value)
Records whether this attribute was in the source text.
Parameters:
setValue
public final void setValue(java.lang.String value)
DOM L1
Assigns the value of the attribute; it will have one child,
which is a text node with the specified value (same as
setNodeValue).
Parameters:
"Attr" implementation. In DOM, attributes cost quite a lot of memory because their values are complex structures rather than just simple strings. To reduce your costs, avoid having more than one child of an attribute; stick to a single Text node child, and ignore even that by using the attribute's "nodeValue" property.
As a bit of general advice, only look at attribute modification events through the DOMAttrModified event (sent to the associated element). Implementations are not guaranteed to report other events in the same order, so you're very likely to write nonportable code if you monitor events at the "children of Attr" level.
At this writing, not all attribute modifications will cause the DOMAttrModified event to be triggered ... only the ones using the string methods (setNodeValue, setValue, and Element.setAttribute) to modify those values. That is, if you manipulate those children directly, elements won't get notified that attribute values have changed. The natural fix for that will report other modifications, but won't be able to expose "previous" attribute value; it'll need to be cached or something (at which point why bother using child nodes).
You are strongly advised not to use "children" of any attribute nodes you work with.