Just want to second what Scott Benjamin said above (and which I’m surprised nobody else said sooner).
The obvious thing to do in many scenarios is to simply write (or generated from XSD) a class which covers your XML schema. You set the properties, you serialize, you deserialize, etc. Simple stuff, clean code.
For alot of real world cases, this is better than either of the solutions being tossed about here.
Precisely my point is not to use string writing.
Either approach (Xml writing or using an object model, either a business object + XmlSerializer or composition of ASP.NET built-in server controls) is generally better.
For trivial cases like the ones you propose Jeff, it may sound OK. But real world is plagued by non-trivial cases, and I know from experience that once you let a lazy developer string-concat a piece of output, they will rarely exercise good judgment as to when it’s just too much.
Other options are separating the rendering of the output from your program logic, by externalizing it in a proper parameterizable template like T4 (from the DSL tools) or CodeSmith or NVelocity, etc. That is actually my preference when you’re not rendering UI.
my 2 cents… the object oriented code isn’t sufficiently abstracted away. I would encapsulate all that crap into a much simpler constuct. Who wants to write all that code over and over?
Perl ftw, btw.
That’s why I like E4x
Boohh to the author of XmlWriter. You can be short in Java as well:
Element parent = …
parent.add( element(“status”).attribute(“code”,"1) )
.add( element(“data”)
.(element(“usergroup”).attribute(“id”,“usr”))
);
parent.flush();
That wasn’t so difficult. And it looks much more OO, since you add atttributes to an element rather than remembering to open and close.
I’ve written some (small) server controls in C# and have to agree that the overhead using the “Writer” classes is ridiculous. I tried it that way for a couple of days and then totally gave up on it. Not only was it a burden to use, but it was generating more bugs because it was VERY difficult to simply look at the code and know whether or not every StartElement() had a matching EndElement() - much more difficult than looking at actual XML. It’s easy enough looking at the simple example in this post, but pepper that with about 50 elements at various nesting levels and your eyes will start to glaze over very quickly.
The DOM model has its uses, to be sure. One example is program options in the Win32 world; yes, .NET has a vast library of persistence classes, but Win32 doesn’t, and when I wanted to store program options in XML it was pretty easy to wrap existing DOM interfaces such that arbitrary new options could be added with just two extra lines of code (one to load, one to save).
A lot of these classes were written to address specific needs, and people shouldn’t assume that simply because it’s possible to use them in a specific situation means that they have to be used in that situation. No best practices!
And XSS is overrated - how about instead of using these clunky writer classes or remembering to escape every single output string, you just escape the form INPUT, once? How many common scenarios are there where you can escape the output but not the input?
I think everyone is missing Jeff’s point. He’s talking about using the right tool/methodologies for the job. Not necessarily a correct, or incorrect way to deliver XML.
Sometimes it is much simpler to just write procedural code than it is to write a full-blown, multi-tiered, object-oriented enterprise application just to create a three element XML document.
My biggest problem with the example given is that visually, the object-oriented method is harder to follow. It’s up to the individual reading the code to mentally keep track of when a tag is opened and closed to tell which are wrapped inside other tags, since Visual Studio will put everything on the same tab level by default.
In the example Jeff provided, it’s simple, but if you’re producing a long XML document, it becomes tough to read.
I won’t argue about your statement that OO may be overkill, but I’ll point a flaw in your argument. Here’s a counter example of a pure OO implementation that is about the same size as the string format example (written in python)
import yaml
x = {}
x[“status”] = { “code” : 1 }
x[“data”] = { “usergroup” : { “id” : 1 } }
print yaml.dump(x)
The output is like this:
data:
usergroup: {id: 1}
status: {code: 1}
There are maps, strings integers, a function (a method from object yaml). Nothing else. Yes, I know that I cheated, that your client or boss wanted it on XML, but you can’t deny it. It’s proof that the OO implementation you chose sucks and there are implementations that are even cleaner than the example you wrote.