Keeping HTML Out of Your Code
The debate that has been raging on, not just for the past six months, nor for the past two years, but at least for the past ten years if not longer, is "how much code should we put in our HTML" ? As dynamic HTML systems come and go, it seems this question gets brought up and answered in some way or another over and over again.
My observation has been that a typical programmer goes through at least two, and sometimes more, stages:
1. Write code, put a bunch of HTML in it - We all know this one since we have all been there. We write a Perl CGI script, then it needs to produce a web page, so, put a big print statement at the end ! Problem solved. The ensuing nightmares of further development and maintenance bring us to stage #2.
2. No code in HTML anywhere - Seeing the evils of embedding HTML and code together lead us to the rational conclusion that they should be forever separate. Tag-based languages are devised to meet the needs of the basic dynamic-HTML trifecta: variable substitution, conditional HTML, and iterative HTML. Most then go beyond. Every programming language has a host of libraries with this task in mind.
When I was reaching stage #2, my company was just beginning to make the shift from Perl CGI scripts into Java servlets. I had already written some small templating languages for Perl (since I didn't know about CPAN) and even one for C (since the high-performance alternative to Perl CGI at that time was, C CGI). Note that I mean servlets, not JSP; JSP hadn't been invented yet. So when the boss wanted a new content management system written in Java, it was time to take all of my template-language skills and apply them to this new world of Java servlets, which until then was the language that I had used to create quirky and buggy client-side applets that talked to chat servers and failed at communicating to Javascript objects via a doomed technology called LiveConnect.
Since that company is long gone, I will announce here that my template language and accompanying CMS was called WebMechanic. WebMechanic achieved the abovementioned trifecta, and for its "beyond" category provided a full expression parser/runtime-evaluator, meaning you could do things like <if a==b && (c!=d || f==g)>MARKUP</if>. WebMechanic was then used for two of the company's client websites, the NFL Players Association and "Gillette Girls", which had something to do with getting teenage girls to start shaving their legs.
WebMechanic obviously does not run anywhere these days and has not for many years. However you can get a taste of WebMechanic by using its official template spinoff, which is known today as FreeMarker, the first version of which was written by a colleague of mine and has since been totally re-done by another group of developers. At least the last time I looked, it remained largely driven off of WM's template philosophy, which of course, being firmly rooted in stage #2, is no Java code in templates !
The immense failure of WebMechanic was that while its template language was quite powerful and featured a runtime stack for arbitrary levels of nesting/expression evaluation, calling includes and allowing all kinds of functions to be performed on the objects sent to it via controllers, it was still a royal pain in the ass. An entire team of programmers had to constantly struggle with every new template concept having a corresponding JavaBean or whatever, and all the while as I continued to hear about JSP, a technology that generated Java source files on the fly, all I could think was what are those guys, crazy ? Embedding Java code and putting it straight into generated source files? What maniacs !
Today, while Freemarker, and its more successful counterparts WebMacro and Velocity are doing just fine, it doesn't need to be said that for every WebMacro or Velocity template written, there are like two gazillion-jillion JSP files created. Why is this ? Because, at the end of the day, tag-based languages that dont let you drop out into code are a pain in the ass. Ask anyone that does XSL all day. Its safe, its clean, sure. But the level of code that has to be constantly devised to support these tag-based languages, in high-speed many-developer/ many-designer/ many-salespeople-bringing-new-crap-to-do-every-day environments is significant. Its view-based work that could often be organized more succinctly and handled by HTML designers completely if a little bit of real code here and there can be used to get you through the day. And I dont mean a lot of code; I just mean the little grease here and there to make certain intricate sections and functions work without having to re-architect a bunch of new objects with HTML fragments embedded into them. JSP with extensive usage of taglibs is possibly a decent mix of a primarily tag-oriented system that isn't forcing it upon you.
Specifically, what ends up happening with an overly rigid template system is that programmers, in order to get more intricate sections of HTML content such as highly iterative layers, Javascript that has to interact with server-side code, etc. into their output is they put the HTML into their application source. Crack open any application that is totally XSL or tag driven, has been under development for over six months by at least four people and I can assure you you'll find some HTML in the application's non-template source code...maybe a CSS name, a composed hyperlink, an <img> tag in a configuration file...I have hardly ever seen an app that doesnt need to break the rules a little bit (and usually, to a moderate degree).
So if it's accepted that a large and serious application needs to break the "rules", why not break the rules in a cleaner way that allows HTML people to have alittle more control over the view? So we go to stage #3.
3. Better we have some code in the HTML, rather than HTML in the code. As we started off, people are obsessed with not having code in HTML. As for me, I am obsessed with not having HTML in my code. Why ? Because I dont want to maintain HTML. There are plenty of HTML authors who can handle it, in fact there is pretty much zero HTML skill these days that doesn't include some Javascript programming, ActionScript programming, etc. HTML designers deal with code just fine. After all of my subsequent years doing JSP and HTML::Mason for at least five companies, I have never seen an HTML designer break embedded code in a template. It just doesn't happen; HTML'ers, while they often don't know how to architect a database-driven applciation, are usually very very good at seeing where your code is and where it isnt. Templates of course must be created with appropriate restraint (restraint which you learned by successfully completing stages #1 and #2); application logic must remain out of templates as much as possible, and database queries are just an urban legend as far as templates are concerned. I guess some people think such restraint is impossible...but excess rigidity is just going to make itself apparent as even uglier hacks somewhere else.
There is still another stage to this though.
4. Tag-based template systems are still good. They are ! Of course they are. What are they good for ? When you want markup written by people you don't know (i.e. outsourcing to India) or who are not really HTML designers at all but due to whatever organizational issue they are stuck editing a little bit of HTML here and there (i.e. Bob in the marketing department needs a section of the site he can author).
Once you go through the four stages of embedding code in HTML, all those folks who are rigidly stuck in stage #2 look pretty silly. Note that it is a skill to differentiate which tag-based template advocates are in stage #4 and which are in stage #2. If you do decide that you need a tag-based template system, its probably best that its developers are stage #4 types, as they are by definition coming from a broader perspective.