Templating is so 1990's
I just had this conversation on IRC, and I thought I would paste what I wrote.
Programming the generation of documents is something we don't need another layer, or another language, to do. However, programming the generation of documents provides an inflexibility we have decided calls for this mechanism we call templating where we use a relatively limited high level language to propigate the contents of and describe the structure of a document.
We however have to interact with this language, giving it datastructures to use to propigate the docuement. After all, the content has to come from somewhere.
The problem lies in the fact that we just did the same thing twice. We generated a document, and then we generated a document. The first document was nothing more than a datastructure as many documents actually are, the second document was generated when the templating language parsed that data structure and ran the template code against it.
Here in lies the flaw with this, the first document we generated is not useful to anything other than the particular templating library we happened to feed it to. This is why transformation is a more sophisticated, and superior approach. Rather than generating one huge data structure in the form of a feed to the templating engine you generated a datastructure in a form that in turn does, or may, generate a document.
Then you use a transformation language to generate your target media from that document as a source. Here is the benefit, the document is forever reusable, particularly since it must be in some kind of computer readable form. Therefor, when you need to ship that data to a different source, you don't have to worry about generating it in a different format. You're already using a computer readable document format as your input source for your human readable document.
The transformational system's data structure is in the form of a document, a prime example (which I know this is where the flames will start, I'm prepared) is the Document Object Model. DOM is a native data structure, it just happens to represent a document. My point is that you end up generating something like this anyway, particularly with web applications were our end goal is to inevitably generate markup. The issue is, you could just as easily generate a document from your application as you could propigate the templating engine.
It has to also be serializable. I use XML as the example because it has the benefit of standards causing it to be a good example of how this approach promotes flexibility and interoperability. This is not a lack of core/ui split. In my example, we are generating the presentation document by transformation. The transformation then does not even need to happen within the application, so the UI has absolutely no effect with nor is it even actually in fact generated by the core application.
We have taken a step back to generating a document. The point is, the document is designed to be computer readable. An XML, or maybe some other type of serializable form, document would be a perfect candidate for this. Then we transform the document into it's presentation form outside of the application entirely. The application now does simply generate documents, it no longer needs to generate documents flexibly. The flexability is added at an entirely different, and even more disassociated, level.
Data needs an exit point in the application. The data leaves in a serializable form. It does not matter what the serializable form is, because we later will transform it with a small set of rules into a presentation document. This set of rules should not have to change, and infact in the case of XSLT for instance, the set of rules doesn't need to change regulardless of the size of the document (within the limits of the capacity of the computer, unfortunately XSLT in particularly uses a DOM-driven approach and thus requires the entire document(s) to be loaded into memory. There are other SAX and StAX based transformation languages which do not have this requirement, though). The point is you no longer have data that only goes out of the application in a non-reusable way. So you no longer need the overhead of dynamically generating the document in an abstract environment such as a templating language.
There was some more, including a few people in the channel finally getting it, but at that point it becomes too obvious it's one side of a two sided conversation for me to try and turn it into an article here.
My point is our programs should not care about what happens to the data they generate. They should not have to worry, internally, about being able to flexibly adapt the output data. And in a way, they don't…but I mean really. I think my program should take in input, and generate output. Who cares if the output is later transformed into a webpage, or an XUL application, or a PDF document, I think the entire application should be disconcerned with this, and that this is the job of an external tool stacked infront of the application to create a UI layer. I'm talking about the fundemental approach of simply generating a document as the exit point of the model layer of an application, rather than interacting with a view layer directly.
A couple of people missed the bus on this conversation. I really don't know why people don't understand what I am trying to say here.
Comment by anonymous on Sat Apr 29 18:54:26 2006
Wonder why nobody ever comments on any of these posts.
