|
Glad to help
|
|
|
|
|
I have a plain XML data file that I want to read into a hierarchy of classes. I'm not sure how do do this. Can someone point the way?
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Well, if the XML tags correspond to class names in a predefined namespace, you can use reflection to invoke the constructors, then more reflection to assign child properties (Maybe have each class implement an interface so you know where the children go)...
Alternatively, you can use something like a factory pattern and recurse through the XML tree manually, which gives you more capability and flexibility while requiring a lot more code both at the beginning and when things change down the road...
Kind of depends on the specifics of the situation.
|
|
|
|
|
There are 2 levels in the XML, and I have classes for both. I'm defining the XML, so I can do this any way I want. I just don't know how to.
I was hoping for some method of automatically loading the XML into a class hierarchy.
Everything makes sense in someone's mind
|
|
|
|
|
Well if this is a load/save kind of feature, you could always just go with serialization. That won't give you very readable XML, but it makes things incredibly easy.
If you intend to create the XML files manually, I'm thinking you'll want something simpler and more flexible than what serialization would give you, so it won't be automatic.
|
|
|
|
|
Ian Shlasko wrote: That won't give you very readable XML
Why not?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Have you ever used XML serialization? They throw in a ton of garbage tags, meta data, etc. to support various features. I wouldn't say its "unreadable", but you would definitely look at it and say "WTF!! why does this XML have so much crap in it?"
|
|
|
|
|
Then use the attributes correctly when creating your objects to serialize. You can also override the methods to create your own structure if necessary.
SledgeHammer01 wrote: why does this XML have so much crap in it?"
The answer is. It doesn't have to.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Beyond the "don't serialize this item" attribute? As far as I know, they still throw in *some* metadata. I could be wrong on that. Yeah, I guess you could reinvent the wheel and completely implement your own serialization without all the extra crap, but at that point, whats the point of using XML serialization? There are much better ways to store data unless you have certain requirements that push you to XML. Using XML because "thats what everybody does", is most certainly not a requirement .
|
|
|
|
|
SledgeHammer01 wrote: Beyond the "don't serialize this item" attribute?
Yea, there are a few more attributes available. Have a look.
SledgeHammer01 wrote: I guess you could reinvent the wheel
No convincing someone with such a closed mind.
Have a nice day anyway
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Calm down dude. I was asking because I wasn't sure.
|
|
|
|
|
Like Sledge said... Namespaces, metadata, escape sequences... Annoying stuff you wouldn't want to see if you planned to edit it in notepad without needing to consult a reference every thirty seconds
But it's all a matter of the objective... For one of my systems, I use my own ToXML/FromXML methods to transmit trade data between the client and server. I don't use serialization, because I want to make sure I have full control over how fields are encoded, and how it behaves if a field is omitted or an extra one is found (In case the client is running an older version than expected). In other parts of the system, I serialize for simplicity.
Of course, it sounds like Kevin's situation doesn't need XML or readability at all, so this is all irrelevant
|
|
|
|
|
Ian Shlasko wrote: Annoying stuff you wouldn't want to see if you planned to edit it in notepad
Well XML Serialization wasn't meant to produce human editable files anyway, rather a means to transport information. But yes, it all depends on the usage and in this case the OP would probably be better off with Binary Serialization, or some other method.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark Nischalke wrote: Well XML Serialization wasn't meant to produce human editable files anyway
Which was exactly my point
Mark Nischalke wrote: But yes, it all depends on the usage and in this case the OP would probably be better off with Binary Serialization, or some other method.
Yep.
|
|
|
|
|
|
Ok, from your first post, I thought somebody is giving you XML that you have to read in. Now I see it is fully under your control. So I must ask: why do you want to use XML? Don't just use it because you *think* you are supposed to. Use it when its *APPROPRIATE*. It often isn't the right choice. People just think they are supposed to use it.
1) do you need it human readable?
2) do you need it human editable?
Before you answer those two questions, let me clarify... say you want to store application settings in an XML file? Your first answer might be "yeah, I want it totally human readable / editable". Why? Do you really want people going in and mucking around with your data files? Are you going to handle all the cases when it gets misformatted by a human? etc?
Now lets get to the real questions:
3) do you need platform interoparability?
4) is data size a concern? is performance? Remember, once your file grows to any reasonable size, xml becomes REALLY slow. At around 200k, it starts to slow down. At around 500k its quite noticable. At around 1MB, its 3 to 4 seconds of load time.
So, anyways, if you don't care about the human aspect and you don't need platform interoparability then XML is must definitely NOT the right choice. Especially if #4 is a concern.
Your best bet then would be binary serialization which is built into .NET as soon as you add the [Serializable] attribute to your class.
|
|
|
|
|
The only reason I thought of XML is because I want an easy way to store the data with the app. Their won't be that much data, and I probably don't want the user screwing with it, so I guess serialization is the best approach.
Everything makes sense in someone's mind
|
|
|
|
|
If you don't want the user to mess with it, then make it Binary. If the user sees something in "English", they might just be tempted to edit it with disastrous results.
|
|
|
|
|
Make it binary
Meaning encrypt it somehow? How would you make it binary?
Everything makes sense in someone's mind
|
|
|
|
|
Write it out using the Binary serialisation formatter. Effectively your code would look something like this:
private void SerializeMyClass<T>(string file, T obj)
{
using (FileStream fs = new FileStream(file, FileMode.Create, FileAccess.Write, FileShare.Write))
{
new BinaryFormatter().Serialize(fs, obj);
}
}
private T Deserialize<T>(string file)
{
using (FileStream fs = new FileStream(file, FileMode.Open, FileAccess.Read, FileShare.Read))
{
IFormatter formatter = new BinaryFormatter();
return (T)formatter.Deserialize(fs, obj);
}
}
|
|
|
|
|
Ok, I see. Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Pete O'Hanlon wrote:
If you don't want the user to mess with it, then make it Binary. If the user sees something in "English", they might just be tempted to edit it with disastrous results.
LOL!!
At a previous company where I worked at, I was "second in command" on my team and the lead *insisted* on using XML so it was human readable. I argued with him for quite a while about it before giving up and moving on with my life.
Fast forward 2yrs later when we finally shipped. Apperently users were screwing around with the XML files and causing issues like circumventing security, etc. So his solution was to just assign strict ownership of the XML file to the windows service so nobody else could touch it (apperently not realizing that anybody with admin rights could reassign ownership).
Oh well... at least I don't work there anymore.
|
|
|
|
|
There have been some great answers here, especially challenging you to think about whether or not you need to use XML at all. If you do, however, then you should have a schema designed to back up your XML - and if you do, you can use the .NET command xsd.exe[^] to generate a class structure that maps to your XML (and thus, your XML hierarchy).
|
|
|
|
|
Ugh... xsd.exe... double ugh.
As an example, here is a simple XML file:
<head>
<items>
<item Name="Item1" />
<item Name="Item2" />
<item Name="Item3" />
</items>
</head>
xsd gave me a clean enough schema:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="head" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xs:element name="head" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="items">
<xs:complexType>
<xs:sequence>
<xs:element name="item" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="Name" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Then it gave me 50k of C# code full of extra crap to read that tiny thing lol.
|
|
|
|
|
I include a property into my objects called XElement:
public XElement XElement
{
get
{
XElement value = new XElement("Item",
new XElement("Property1, property));
return value;
}
set
{
if (value != null)
{
property = GetValue("Property1", defaultValue);
}
}
}
GetValue is a heavily overloaded extsension method for the XElement class that takes care of parsing for the appropriate data type. I posted a tip/trick here:
Using Extension Methods To Avoid XML Problems[^]
After you'cve defined your XElement property, you can add a constructor to your item class like so:
public MyItem(XElement value)
{
this.XElement = value;
}
As you're reading your XML data, you can simply Add each new instance of MyItem to a collection as you read the data in.
Easy-peezy, lemon squeezy...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|