I have a simple class that essentially just holds some values. I have overridden the ToString()
method to return a nice string representation.
Now, I want to create a ToXml()
method, that will return something like this:
<Song> <Artist>Bla</Artist> <Title>Foo</Title> </Song>
Of course, I could just use a StringBuilder
here, but I would like to return an XmlNode
or XmlElement
, to be used with XmlDocument.AppendChild
.
I do not seem to be able to create an XmlElement
other than calling XmlDocument.CreateElement
, so I wonder if I have just overlooked anything, or if I really either have to pass in either a XmlDocument
or ref XmlElement
to work with, or have the function return a String that contains the XML I want?
XmlElement is just one kind of XmlNode. Others are XmlAttribute, XmlText etc. An Element is part of the formal definition of a well-formed XML document, whereas a node is defined as part of the Document Object Model for processing XML documents.
Elements are one of the most common nodes in the W3C Document Object Model (DOM). Elements can have attributes associated with them. The XmlElement class has many methods for accessing attributes (GetAttribute, SetAttribute, RemoveAttribute, GetAttributeNode, and so on).
The XmlDocument represents an XML document. It can be use to load, modify, validate, an navigate XML documents. The XmlDocument class is an in-memory representation of an XML document. It implements the W3C XML Document Object Model (DOM).
I would recommend to use XDoc and XElement of System.Xml.Linq instead of XmlDocument stuff. This would be better and you will be able to make use of the LINQ power in querying and parsing your XML:
Using XElement, your ToXml() method will look like the following:
public XElement ToXml() { XElement element = new XElement("Song", new XElement("Artist", "bla"), new XElement("Title", "Foo")); return element; }
From W3C Document Object Model (Core) Level 1 specification (bold is mine):
Most of the APIs defined by this specification are interfaces rather than classes. That means that an actual implementation need only expose methods with the defined names and specified operation, not actually implement classes that correspond directly to the interfaces. This allows the DOM APIs to be implemented as a thin veneer on top of legacy applications with their own data structures, or on top of newer applications with different class hierarchies. This also means that ordinary constructors (in the Java or C++ sense) cannot be used to create DOM objects, since the underlying objects to be constructed may have little relationship to the DOM interfaces. The conventional solution to this in object-oriented design is to define factory methods that create instances of objects that implement the various interfaces. In the DOM Level 1, objects implementing some interface "X" are created by a "createX()" method on the Document interface; this is because all DOM objects live in the context of a specific Document.
AFAIK, you can not create any XmlNode
(XmlElement, XmlAttribute, XmlCDataSection
, etc) except XmlDocument
from a constructor.
Moreover, note that you can not use XmlDocument.AppendChild()
for nodes that are not created via the factory methods of the same document. In case you have a node from another document, you must use XmlDocument.ImportNode()
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With