[quoted text, click to view] "Pascal Schmitt" <newsgroup@cebra.nu> wrote in message news:e%2316iJuwFHA.612@TK2MSFTNGP10.phx.gbl...
> For some reason you can't create XmlNode-s (XmlNode, XmlElement, XmlAttribute...) by their constructors - you have to use the
> CreateXXX-Methods provided by your XmlDocument
One of the reasons is so XmlDocument can set itself as the owner of the
XmlNode (why I need to use ImportNode( ) to move an XmlNode out
of one document and into another).
It seems subtle, but this factory pattern allow DOM implementations to
make some optimizations in how it keeps tabs on the XmlNodes that
may one day be joined to it. I'd expect, after all, if I created an Xml-
Element from an XmlDocument that I'm going to AppendChild it to the
same document soon, rather than import it to another XmlDocument to
append it there. I don't believe .NET's XmlDocument makes any opti-
mization of this sort, but it would be possible. Besides, if there were a
public constructor, everyone would be running around with orphan nodes.
Also, XmlNode in particular is an abstract base type, so an XmlNode
by itself or even a subclass of an XmlNode that isn't one of the pre-
determined types wouldn't fit into the XML Infoset.
[quoted text, click to view] > but /not/ add it to the XML-tree, you have to do it yourself (for example
> using AppendChild)
The factory methods don't add the XmlNode into the XmlDocument
themselves because it'd require a lot of additional information (where:
before, after, or as a child of; and in relation to what context node).
Sometimes this could be a convenience, since as I've said, we're
usually going to add the XmlNode to the same XmlDocument we've
just created it off of. There are still times when I might want to defer
appending the nodes, though. For example, when recursing depth first
over some object graph to build an XmlDocument from the leaf nodes
up.
Derek Harmon