If the attribute has not been explicitly assigned a value, but has
been declared in the DTD, it will exist and have that default. Only
if neither the document nor the DTD specifies a value will the
Attribute really be considered absent and have no value; in that
case, querying the attribute will return null.
Attributes may have multiple children that contain their data. (XML
allows attributes to contain entity references, and tokenized
attribute types such as NMTOKENS may have a child for each token.)
For convenience, the Attribute object's getValue() method returns
the string version of the attribute's value.
Attributes are not children of the Elements they belong to, in the
usual sense, and have no valid Parent reference. However, the spec
says they _do_ belong to a specific Element, and an INUSE exception
is to be thrown if the user attempts to explicitly share them
Note that Elements do not permit attributes to appear to be shared
(see the INUSE exception), so this object's mutability is
officially not an issue.
Note: The ownerNode attribute is used to store the Element the Attr
node is associated with. Attr nodes do not have parent nodes.
Besides, the getOwnerElement() method can be used to get the element node
this attribute is associated with.
AttrImpl does not support Namespaces. AttrNSImpl, which inherits from
AttrImpl used to inherit from ParentNode. It now directly inherits from
NodeImpl and provide its own implementation of the ParentNode's behavior.
The reason is that we now try and avoid to always create a Text node to
hold the value of an attribute. The DOM spec requires it, so we still have
to do it in case getFirstChild() is called for instance. The reason
attribute values are stored as a list of nodes is so that they can carry
more than a simple string. They can also contain EntityReference nodes.
However, most of the times people only have a single string that they only
set and get through Element.set/getAttribute or Attr.set/getValue. In this
new version, the Attr node has a value pointer which can either be the
String directly or a pointer to the first ChildNode. A flag tells which one
it currently is. Note that while we try to stick with the direct String as
much as possible once we've switched to a node there is no going back. This
is because we have no way to know whether the application keeps referring to
the node we once returned.
The gain in memory varies on the density of attributes in the document.
But in the tests I've run I've seen up to 12% of memory gain. And the good
thing is that it also leads to a slight gain in speed because we allocate
fewer objects! I mean, that's until we have to actually create the node...
To avoid too much duplicated code, I got rid of ParentNode and renamed
ChildAndParentNode, which I never really liked, to ParentNode for
simplicity, this doesn't make much of a difference in memory usage because
there are only very few objects that are only a Parent. This is only true
now because AttrImpl now inherits directly from NodeImpl and has its own
implementation of the ParentNode's node behavior. So there is still some
duplicated code there.
This class doesn't directly support mutation events, however, it notifies
the document when mutations are performed so that the document class do so.
WARNING: Some of the code here is partially duplicated in
ParentNode, be careful to keep these two classes in sync!