Nice work. I always thought this was a bit more work than necessary. Have any thoughts on doing something for files and streams in System.IO?

Granted is not the fastest or most efficient way, but it does look good and it seems allot more maintainable to me. Maybe if you have a 10MB xml file you should use XmlWriter, otherwise I would go with this fluent interface.

In the blog comments someone said : why not use link ? - I'm pretty sure you can't do this with link :

XmlOutput xo = new XmlOutput()
.XmlDeclaration()
.Node("root").Within()
.Node("numbers").Within();

for (int i = 1; i <= 10; i++)
xo.Node("number").Attribute("value", i.ToString()).InnerText("This is the number: " + i);

damn ... we need some code tags :))

Well, you might be familiar to the XmlWriter api, i'm not - so when looking at your code and his code, the wrapper looks nicer, and easyer to understand to me.

And i'm not really sure how many know the XmlWriter api so well that they would find hard to read and understand the fluent interface one.

Oh , and at the comment above when i kept writing "link" i meant "linq" :D

Ralph,

I won't go ahead and say that this is a universal replacement for XmlWriter. XmlWriter definitely has it's merits, for instance if you're doing some large document XML handling. That being said, if you're not doing that, then maintanability and readability ought always be your primary concern, and imho, the XmlOutput method is a lot more readable.

Correct, not everyone will know the XmlOutput class, but most will find it easy to understand nonetheless. Furthermore, if we make it a requirement for everyone to know everything, why are we not writing x86 asm, after all that's somewhat easier to memorize than the .NET framework :)

And regarding the LINQ bit (which isn't actually LINQ, just a 3.5 feature, but everybody, including me, somehow manages to call it LINQ), I really despise the nestedness of it, the way any XML document creation will end with an ugly amount of closing paranthesises.

And finally, as I also mentioned on the blog, using XmlWriter inhibits you from accessing the underlying XmlDocument if needed.

I also like the fact that it can be used 'fluently'. I prefer this approach then XmlTextwriter, but indeed, probably not that good performing. But then again, who cares about performance these days, right? :)

<low whisper>I see winky people.</low whisper>