Posts tagged ‘Array’

Options for serializing an Array or List when using Serializable?

Lets say you have to implement Xml Serialization on your objects. Many of your exiting Xml files have Lists. However, what if you are working with existing Xml files and you don’t get to reformat them? So you have to make the List in your object react the way it already looks in possible poorly designed Xml Files.

Ok, so off the top of my head, I can think of many ways that a List of objects could be displayed in XML (and there are probably more). For simplicity’s sake, I am going to use String objects for this, but this goes along with any object.

So how does Xml Serialization hold up when confronted with existing Xml files and existing lists?

Well, lets first show you some example Lists in Xml and then lets see what types are supported.

Type 1 – Grouped Lists

Status: Supported – This is the default way Xml Serialization stores lists in Xml files.
Xml Design: Excellent.

The object elements are contained in a parent element. As shown, each String element is inside the Strings (notice it is plural) element.

[sourcecode language=”xml”]


Some string 0.
Some string 1.
Some string 2.
Some string 3.
Some string 4.


[/sourcecode]

Type 2 – Grouped Lists numbered

Status: Unknown – I haven’t found a way to do this yet, but I am not ready to say it can’t be done.  If it can’t be done, I think it “should be” supported.
Xml Design: Average. I am not sure if you can serialize this. Someone designing an Xml without serialization in mind would not think this design is wrong.

Same as above only each element is numbered incrementally from 0. (Or it could start at 1, right?)

[sourcecode language=”xml”]


Some string 0.
Some string 1.
Some string 2.
Some string 3.
Some string 4.


[/sourcecode]

Type 3 – Flat List

Status: Supported – If you add [XmlElement] above the property, then this is the format you get.
Xml Design: Excellent. This is a standard supported format.

There is just a list, with no parent attribute containing the list items.

[sourcecode language=”xml”]

Some string 0.
Some string 1.
Some string 2.
Some string 3.
Some string 4.

[/sourcecode]

Type 4 – Flat List numbered

Status: Unknown – I haven’t found a way to do this yet, but I am not ready to say it can’t be done. If it can’t be done, I think it “should be” supported.
Xml Design: Average. I am not sure if you can serialize this. Someone designing an Xml without serialization in mind would not think this design is wrong.

Same as the Flat list above only each element is numbered incrementally from 0. (Or it could start at 1, right?)

[sourcecode language=”xml”]

Some string 0.
Some string 1.
Some string 2.
Some string 3.
Some string 4.

[/sourcecode]

Type 5 – Attribute Lists

Status: Broken but working – If you put [XmlAttribute] before and Array or List, beware. It seems it uses space as the delimiter. I can’t seem to find a way to change the delimiter.
Xml Design: Poor. You can serialize this, but it deserialize the same way as it serializes.

A single attribute that contains a list. Obviously the object can’t be complex to match this type.  String works, but a complex object has to be an element not an attribute.

I can already see that this method would be tough to use. Right away I am wondering seeing the problem of using white space as a delimiter. However, quotes are important too. Xml Serialization automatically replaces quotes with the following string:

[sourcecode language=”text”]

[/sourcecode]

I would have thought since it uses a space as a delimiter that it would have replaced white space with some similar character entity string, but it did not.

[sourcecode language=”xml”]


[/sourcecode]

Type 6 – Attribute Lists numbered

Status: Unknown – This is what I expected when I used the [XmlAttribute] tag but instead I got Type 5.  I have seen this in Xml files, so supporting it would be nice.
Xml Design: Average.  If a List exists that is always expected to have only one to five elements, I see nothing wrong with this design.

A separate, numbered attribute for each element in the list.

[sourcecode language=”xml”]

[/sourcecode]

Type 7 – Delimited text in an element

Status: No supported – This just is not how it is designed to work, nor should it every work this way.
Xml Design: Poor – This defeats the whole purpose of an Xml.

This assumes that the list is inside a single element and has some kind of delimiter. Below the delimiter is a new line character. (Let’s assume that we expect white space at the front and end of the string to be trimmed and blank lines to be ignored.)

[sourcecode language=”xml”]


Some string 0.
Some string 1.
Some string 2.
Some string 3.
Some string 4.


[/sourcecode]

Conclusion

Type 1 and Type 2 are the ideal methods and work perfectly for me.

Types 2, 4, 6 should be supported if they aren’t already.  Maybe there is a way to do these that I don’t know about.

Type 5 seems to work but doesn’t and it is really disappointing that the [XmlAttribute] tag works this way instead of like Type 6.

Type 7 is bad and you pretty much are left to fixing this with manual code and not using Xml Serialization.


Copyright ® Rhyous.com – Linking to this page is allowed without permission and as many as ten lines of this page can be used along with this link. Any other use of this page is allowed only by permission of Rhyous.com.