When Object-Oriented Rendering is Too Much Code

I agree with Jeff to a degree, and others that it’s mainly the interface of .NET’s current Xml objects that cause the suckage.

Just for shits and giggles, go read this article on Lisp:

http://www.defmacro.org/ramblings/lisp.html

…And then check out Sahil’s series of articles on what’s coming for C# 3.0:

http://linqinaction.net/blogs/sahilmalik/archive/2006/06/18/24.aspx

All I can say, is that it looks like Microsoft is on the ball with this issue.

If you want to write out a small amount of XML quickly then your approach of just doing it works OK and is, as you say faster to code. It allows you to generated structured content in an unstructured way.

I guess using the DOM approach would be a midway house in coding verbosity. Always thought the XMLReader and XMLWriter were designed out and out for execution speed and low memory usage rather than developer productivity.

I guess LINQ will help here ?

As noted in other comments there is a best of both worlds… which is really helpful when creating larger documents that have a lot of boilerplate…

doc new XmlDocument(new XmlTextReader(boilerplateInString))

and then XPathNavigator over this to navigate to nodes and set the real values.

Use the object model where it gives value (handle the right encoding, serialising the document, getting the syntax right), and the easy way when applicable.

XPathNavigator.AppendNode(XmlReader) and similar methods also allow insertion of many nodes.

The fun stuff comes when you have an entire complicated system building xml, xhtml or x(something else?) documents. Have you guys looked at the differences from .Net(c# or vb.net), php to ruby? I know that it would be a sin for some people here :), but imagine you should port your vb.net oo xml generation stuff to ruby? That would be quite a lot of rewrite if you ask me.
You don’t always need valid xml, sometimes it is just enough with well formed xml documents. Of cause we should always try to do better, but I don’t think you need to use all your gun powder on every line of code you write. If the xml you generate needs to be very strict formatted then yes you should of cause provide valid xml, but if it just is some little test application that needs a simple xml save function, then do it fast. Suit the code for your needs. There is NO correct way to generate xml. And that is how it should be.

E4X is a nifty Javascript enhancement that makes XML a first class type.
So in E4X the code would look a lot like the string example, but instead of being a string, it would be an XML data-structure.

The XML elements become exposed as properties on the object holding the object graph:

var x = status code="" /
data
usergroup id="" /
/data
x.status.@code = 1
x.data.usergroup.@id = “abc”

Is it just me or does the ‘OO’ version appear to be just procedural code using an object-based API? The repetitive work doesn’t seem to be abstracted at all.

Surely an effective OO API would allow me to take what we know about XML (such as that tags that pertain to content have closing tags).

So where does that leave us? The ‘OO’ way is an example of a poor interface (and not many seem to disagree here). The ‘short’ option might be served by a template approach if you are just formatting a message to another system. Nothing would stop you doing this in a succinct OO manner either.

We develop in PHP primarily - if we had 1 message to create it would be just a hand-typed string. When the requirements change it would likely have further OO abstractions applied (we don’t like operating in global scope so we’d have started in the scope of some object or another…)

Since it seems like it will help most of the commenters:

Forest -

  • Trees

In the .NET world, couldn’t you create a class called “data” (or whatever) which has a property that is a class called “usergroup” with property id.

Then you could create an inheritable class that itself inherits the XML Serializable Class and create a function in the base class that outputs your class as XML, using the appropriate “ignore” and “attribute” functionality available to the XMLSerializable class.

Then, your inherited class already has the mechanisms to output that object directly as XML, plus it’s well-tested code (I assume) by Microsoft and the community.

This seems to me to solve the problem of a) type-safe security and b) error-prone XML and c) Happy-go-lucky OO.

But, I agree the XML Classes are cumbersome at best. In the words of Larry the Cable Guy sometimes you just have to “git 'er done”.

I hesitate in posting to this group as I don’t consider myself to be a “programmer’s programmer”, so if there are flaws in my plan please feel free to let me know :slight_smile:

This may be a bit of a stupid point but the example is exactly the kind of situation where you are putting the data in an xml document just because XML is what people use. There are loads of entirely valid uses for XML but anything that is simple enough for a trivial example is very likely to actually be so trivial that you might be better off just using plain text file with some simple formatting.

The outcome of that is that everyone ends up criticising the example and ignoring the point you were trying to make. Just like I have just done.

For me, the problem with the XML libraries pretty much reflects the problem with XML itself- I’m all in favour of interoperability but I don’t think I necessarily need that much verbosity for everything I do…

In my personally experience as soon as developers start using string variables to hold XML we start getting invalid XML problems. And when one system is passing XML around to other systems this is a real pain. Unless the XML is ridiculously trivial I would stick to using objects if you can.

Its called a Templating Language and its not just good for XML, but for (X)HTML, email, reports, whatever. String.Format() is just a very very simple templating engine. From an OO/Architechture standpoint I think this is actually better because it means the view isn’t mixed in with the rest of your code. And like Jeff said, its faster, easier to understand, less code and more maintainable.

I don’t think it’s the OO either that’s the problem. xw is supposed to be Xmlwriter. So,
why are we having to tell it to writeThis, writeThat, and writeTheOther? All those methods should lose the first 5 chars from their names. If it is to do something else with them, then be explicit.

If we can’t have blocks, as per the Ruby example, then why doesn’t startElement take the attributeString and the nested element as parameters? It’s not just the RSI of typing that
would be saved, it’s the cognitive load of the poor person who has to maintain it later.

Using the code example in this article as an argument on when and where or even the validity of using OOP principles and code is like using a flower to compare and examine the properties of a human. They both are organic creatures, to be sure, but there the simularity ends. Thier concept and deterministic purpose is simply at odds with each other. So too are the comparison of coding methodologies behind script oriented code and object oriented code. They not only come from different worlds and have differnt histories, thier intent for solving problems are completely different. Scripting languages like classic asp, sql, pearl and others are simply relative language scripts that at some point have to be interpreted and transformed back into objects in c++ or some other object oriented languages anyway. Object oriented languages were born to help programmers who were originally programming thier code in assembly to have more tools and prevent them from performing repetitive and non-automated tasks. Scripting languages as well, were designed to perform a specific task, to allow simplistic access to functions and creation of an underlying oo framework in a simplistic manner. I have been presented with the argument that making a simple primitive script in code is more efficient than using objects, thus:

for(i = 0;isomeValue;i++)
object obj = collection[i]

is more efficient than

foreach(object obj in collection)

because the first uses a simple iteration script and the second uses an iterator object to index through the collection. This is true for a very simple application, because the first way you are minimizing the number of objects in memory i.e no iterator object. But what if you have a more complex model? What if instead of a simple collection iteration you had a hundren thousand word essay to parse? Using a simple primitive collection of objects would be very inefficient then. So mabey choosing a Flyweight pattern to share instances of characters instead of creating them over and over in memory seems to be the more effective and optimized way to do things.
To understand something you don’t first refute it before you understand it, you understand it then form your opinions on your new understanding. It seems like many junior programmers like the author has not had the experience to understand why you use oop and when not to. More complicated problems simply take a better solution. I do understand that some programemrs who have found themseleves on the positive side of understanding something about code can be quite enigmatic and arrogant about thier knowledge, or maybe do not communicate thier knowledge in an effective manner, which puts off people who do not have this knowledge. Or maybe you are making a good point when you say that oop does not cover every situation, which I would agree with because no single soution is a global boilerplate in computer sciences. But what the author needs to understand is there is a reason that evolves around understanding and thought towards a problem, and part of the understanding revoleves around understanding all the tools availiable without prejudice. Too often I have heard junior developers say that they don’t understand why you use oop principles, when this other way is simpler. That argumentative attitude puts you at odds with knowledge. It would be better to ask questions and compare notes with other developers, and educate yourself into a place where you can make a competant argument towards a solution based on knowledge, instead of bullishly refusing to investigate your facts first. Just a thought, but in my mind arrogance in programmers is like having your trash man tell you your garbage stinks. No matter how smart any of us are, there are thousands smarter. So why waste time? Thanks for reading.

Ruby is like orange zest in chocolatte, it just makes everything better.

I think the .NET XML classes were designed by the same kind of people who worked on XSD. To paraphrase Capote, they aren’t programmers, they are typists.

cfprocessingdirective suppresswhitespace=“yes”
?xml version=“1.0” encoding=“utf-8” ?
cfxml variable=“xmlDoc"
root
status id=“1”/
data
usergroup id=“1”/
/data
/root
/cfxml
/cfprocessingdirective
cfdump var=”#xmlDoc#"

Jeff, I was simply going to say “Amen!”, but then I saw the hailstorm you set off.

Hmm… mostly minor details and missing the point.

Eh, I’ll just do it anyway. Amen, Jeff, and thanks for piping up!

Ideally you would want your C++/.NET/Java/etc parser to be able to internalize an XML Schema, and then allow you to simply write any expression that would be valid under the schema. You would get compile errors if you are writing XML that doesn’t match the schema.

It’s type-safety without the bullshit of strong-typing.

It’s true, Ruby’s Builder::XmlMarkup absolutely destroys anything else in terms of object-oriented XML construction.

Your XML fragment, as produced by Builder::XmlMarkup:

xml = Builder::XmlMarkup.new(:indent = 2)
xml.status(:code = 1)
xml.data do
xml.usergroup(:id = ‘usr’)
end
output = xml.target!

All of the data is escaped, all of the tags are closed, and the code looks almost exactly like the output. Shazam.

Rob, the first thing that comes to mind when I think “when object-oriented rendering is too much code” is not “you should go ahead and hack it together using strings.” I usually think “then it’s time for a new XML library.”

More generally, if using an object model requires writing reams of soul-crushingly verbose code then it’s not time to reconsider whether or not you should continue to employ an object model; rather, it’s time to reconsider whether or not you should continue to employ the person who wrote the object model.

Given a constrained choice between “XmlWriter And The Dance Of Ten Thousand Functions” and “Just Don’t Ever Use Ampersands”, the latter is of course easier. But the choice is rarely so constrained, hence the number of people chipping in with their favorite language’s substantially less verbose way of pooping out XML.

I wrote an XmlClassWriter and XmlClassReader once. It wrote and read a class to and from XML. It’s very useful, as alot of the time I am just saving classes or arrays of classes to XML to save the state of something.
It wouldn’t be able to easily write the fragment you showed, but to writing a class like:
Card
Suit datatype="Suit"Clubs/Suit
Pip datatype="Int32"3/Pip
/Card
You would do something like:
public class Card : XmlBaseClass
{
public Suit Suit = Suit.Clubs;
public int Pip = 3;

public Listobject GetXmlProperties
{
Listobject xmlProperties = new Listobject();
xmlProperties.Add(Suit);
xmlProperties.Add(Pip);
}
}
And then you would use new XmlClassWriter().Write(new Card());

I really should finish it, polish it and publish it. It’s very useful rather than re-inventing the wheel alot of the time.