Server-side Scripting and Templating
Summary: The web publishing/applications industry (generally) has learned to separate content from user interface, to our great benefit. The next step, separating templates from scripts requires an equally large mental leap, but should yield an even greater reward. Here's how to make our lives easer.
Remember when a "template" was something you opened up, and then pasted content into? And then, when you needed to change the template, you had to change every file? The horror!
Programmers have given us any number of technologies that keep the content out of the user interface: Active server pages, Java server pages, Vignette, etc. We are one step ahead, but it is not enough.
Now the pain comes from templates that include both scripts and html markup.
This, by the way, is very convenient -- in the short term -- for the scriptors. They can create a page in practically no time. In fact, one template can generate many pages, typically a blank or pre-populated form, the potential error page, the preview/accept page, and perhaps even the confirmation page.
To have one template generate several different pages, the programmer uses a "control structure". Code in the template will specify something like "under condition A do all of these things, but under condition B, do all of these different things. One condition might be that a required field on the form wasn't filled in. Another condition would be that everything was filled in correctly. Another common set of conditions are whether certain information exists. For example, if there is a picture to go along with this product, add all of this code (the image tag, a caption, perhaps changes to the page layout), otherwise add all of this code (perhaps the logo of the manufacturer. It gets very complicated, very quickly.
When the programmer is done, he/she typically gives it to the graphics person, who is supposed to make the page(s) look pretty. The poor graphics person, though, isn't a programmer, doesn't want to be, doesn't understand control structures, and yet is forced to find seemingly random places in the long block of code where the "look and feel" gets added in.
Worse yet, a few weeks later, the programmers make some changes, and the graphics person has to figure out what changed and where to make html changes. Worst of all, browsers being as glitchy as they are, sometimes an extra space in the output of the script will make a big, ugly difference in the way some browser displays the page. The graphics person just doesn't have the background to determine efficiently whether the problem is in the script parts, or the html parts.
We should remember that Microsoft's Active Server Pages technology was designed before the web was popular. It was meant to compete with AOL. Companies were supposed to keep a few pages on Microsoft's version of AOL. Instead, companies are trying to maintain hundreds and thousands of pages, forms, and applications. Meanwhile the web is changing at an astounding rate, so all of those forms and pages keep changing and changing. This isn't what Active Server Pages technology was designed for.
All of the "server page" technologies have the same limitations. Java Server pages, Cold Fusion, Vignette, PHP, etc., etc., etc.
Why do the alternatives share the same basic limitation?
The first answer is cultural, I think. The web is a new thing. It brings together people from many different careers: database, programmers, design, etc. No one has much experience with the web -- it's only been around for a few years.
Each career group looks at the web through the skills they've already developed. Designers, for example, thought the web was desktop publishing, and were humbled when they saw their beautiful web pages completely mangled on someone else's computer. The web is not a Macintosh.
Databases evolved to restrict access to information, and generate a new report with each request. Programmers had used "include" files with their compilers, and so their first approach to websites was to use include files.
The web isn't one-size-fits-all what-you-see-is-what-you-get. Neither is it the same as database reporting or compiling software.
We're at the second phase of the programmer approach to website building, because now websites are interactive. (Simply including the user interface isn't enough.) Now the content templates themselves have becomes scripts.
The issue between scripting technologies is usually the language: do you want to write in VBScript, Java, TCL, Perl, etc.?
Why is it hard to separate the look and feel from the program logic?
The first issue is that it adds a step in first creating the page. It means you would need the programmer and the graphics person to cooperate at the start. This is not something that programmers want to do, and it adds complexity. On the other hand, separating the look and feel from the program logic makes the templates much easier to maintain over the long run. Programmers as a culture don't automatically make ease of maintenance a priority. It has to be learned, and often enforced.
The second issue is that it's easy, convenient, and common to think of a template as a file. You put everything to do with the template in one file, and you edit files one at a time. Further, any one file contains only one template, and nothing else.
If you start with that view of a template, you can still do a little better than active server pages. Kiva, which is now Netscape (or AOL or Sun) Application Server (?) was pretty good at separating the template with html markup from the Java code. The html template contained no programming logic, only variables. In the best case, the Java code contained no html markup. At its best, it worked well.
There were still coordination problems between the programmers and the graphics people. In one case the manager of the html coders insisted that all html tags should be upper case. The programmers, though, were using upper and lower case characters in their urls. This still wouldn't be a problem, except that the html software (an early version of HomeSite) would make the urls all upper-case -- because the programmers didn't put quotes around them. The point of this anecdote is that it's hard to get things to work smoothly when you have different groups of people with different background and different tools.
The point at which Kiva broke down, is the fundamental problem with the one-file view of templates. Imagine you have a file in which there's stuff at the top and bottom, but in between there is a set of rows of data. Now imagine that the data should be formatted slightly differently on different rows. If a template is one file, how does it know to use a part of it for several rows? Kiva had an attribute ("tile" I believe) that meant that a certain tag should be used repeatedly. But that only worked for a single tag. The easiest thing for the Java programmer to do was to put one tag into the html template to stand for all the rows. This means that the markup for the row has to be in the Java code. If the look and feel changes slightly, the graphics person has to get the Java programmer to make the changes and recompile the Java servelet. If it isn't quite perfect, they repeat the process. Neither the graphics person nor the programmer is very happy with this procedure.
What else can you do?
We need hierarchical templates that are addressed not by filename, but by template name. We need a template compositor that, for a given page, puts together in one file all the templates required to build the page, and later breaks the page apart to store the templates separately. And we need editors that can make parts of a page not editable. This way you can see the whole page composed of many templates, but you can't accidently change part of a wrong template.
It turns out Macromedia Dreamweaver does all of that (and more), but in a closed system: everyone would have to use Dreamweaver, and only Dreamweaver could be used.
By the way, Dreamweaver also mitigates or solves (haven't used it myself) the other big problem, which is to keep the site structure separate from the user interface, again, as a closed solution. Dreamweaver's wysiwyg editing environment is very slick, but in my opinion slightly mis-guided. Writers and people building one page at a time need wysiwyg editors much more than designers who create templates. It also promotes the illusion that it's good enough to make one or two versions of a site, when in fact there are probably three to five different versions of a site that are necessary.
Copyright © 1998-2011 J. R. Boynton