I don't want templates, I want HTML-making shortcuts

by Derek Sivers

Related link: http://www.oreillynet.com/pub/wlg/4863



In my previous post called Getting PHP to make the HTML for me - I mistakenly called what I was doing a template system. But I don't want a template system. I want shortcuts, inside PHP, that output the HTML I need.

All good geeks know that repetition of information is usually a problem waiting to be solved. HTML (even in templates) is filled with SO much repetition I can't help but try to optimize my use of it.

But first - here's a couple examples why I don't want to use templates for my web-making:

One template extreme: mostly static HTML with some variables:

<html><head><title>{$title}<title></head><body>
<table border="0" cellpadding="5" cellspacing="0">
<tr><td class="bgcolor1">
<h1 class="header">{$title}</h1>
</td></tr>
<tr><td class="navbar">
{$navigation_here}
</td><td>
<h2 class="title">{$article_title}</h2>
<p>{$article}</p>
</td></tr>
<tr><td>
&copy; {$year} {$author}
</td></tr></table>
</body></html>

My problem with mostly-static templates:

Why not just use PHP? In that sense PHP *is* a templating language. Why wrap a new language around something that PHP already does just fine? Better explained in Brian Lozier's article on Template Engines. A great read.




Another template extreme: mostly display-logic and variables with some HTML inside:

{include file="pagetop.tpl"}
{if isset($invalid)}
Invalid edit option ({$edit})
{else}
{foreach key=fieldname from=$fields item=element}
{if $expert or !$element.expertonly}
<tr><td width="40%" align="right" valign="top">
<b>{$element.description}</b>
{if $element.subdesc}
<br /><span class="tiny">{$element.subdesc}</span>
{/if}
{strip}
</td><td width="60%" align="left" valign="middle" class="small"
{if $element.crucial} bgcolor="Yellow"{/if}>
{/strip}
{if isset($notype)}
<p>Not ready to upload yet</p>
{else}
{assign var="file" value=$element.type|concat:".tpl"}
{include file="Backend/Bits/$file"}
{/if}
</td></tr>
{/if}
{/foreach}
{/if}
{include file="pagebottom.tpl"}

My problem with mostly display-logic and variables templates:

Again - why not just use PHP? Look at that code example, above. 26 lines of code, and only 6 lines are actually HTML. Why even be in a template, then? Why not just stay in PHP and generate those occasional tidbits of HTML when you need them?

I disagree with the philosophy that tries to keep the "poor non-technical graphic designers" away from PHP, giving them an "easier" system like Smarty or any other template language. Again: why not let them use PHP for their template-logic? It's much more documented and well-known than any special template-language you can throw at someone.

I make very interactive websites. Full of display-logic that will (for example:)

  • display different flags if an item is on sale
  • use different image sizes based on how many images are shown at once
  • totally change the look and feel if clicking from a partner site
  • show different languages and currency based on your settings


As you can imagine, using template files for this kind of on-the-fly display logic was getting ridiculous.

I decided I don't want to leave PHP anymore to output the occasional HTML tags around my variables.

That's where my head was at when I wrote the last post, "Getting PHP to make the HTML for me".

Read that, if you haven't, then let's move on to the next idea: basic HTML building blocks.

Your thoughts on this so far? Do you use and love templates for interactive sites? Am I missing the point, here?


10 Comments

bazzargh
2004-05-14 02:03:20
A couple of points...
"Again: why not let them use PHP for their template-logic? It's much more documented and well-known than any special template-language you can throw at someone."


2 reasons: tool support, and previewability (if there is such a word). Here we wrote our code to understand the dreamweaver template system, so - so the question of learning "some special template language" didn't ever come up. This strategy means they have tools designed to edit and preview the templates - do you have these for your system?


Another deliberate effect of this is that we don't need working code to show marketing/the customer how the site will look - it will look /exactly/ like the mockup. Mixing code and html means there'll be a gap between the mockup stage and the working code while you copy-and-paste (or convert) the html to php calls. How do you know you've stayed faithful to the original html? How do you deal with updates to the look & feel?

I'd also suggest you read Terence Parr's
excellent paper on template separation


Its a more formal take on things than Brian Lozier's, well worth reading. He makes a good point in the conclusions that argues against "real" languages in templates:


Unfortunately, engines merely encourage
separation while still supporting constructs that allow programmers to violate separation. Programmers will often use these constructs as an expedient or because of lack of experience


Now there's a familiar slippery slope...

dscotson
2004-05-14 04:55:28
Use more CSS for seperating content and presentation

This is semi-offtopic but I note in your examples of why you need these HTML writing PHP shortcuts you mention as a requirement, the ability to "totally change the look and feel if clicking from a partner site" and the have the following code in your brief example:


{if $element.crucial} bgcolor="Yellow"{/if}


which should really be:


{if $element.crucial} class="crucial"{/if}


and in the .css file:


.crucial { background-color: yellow }


Linking a second (or third) .css file could of course change this, and any other purely visual elements easily to match a new affiliate.


This structure/presentation split is another important simplifying device useful for keeping web 'programming' (structural logic) and design separate, which is useful, even when both tasks are being done by the same person. Losing the table based structure (at least to some degree) can also increase code clarity.

applematters.com
2004-05-14 06:36:19
check out expression engine
You should check out expression engine a weblogging/cms system that uses php and mysql. Using expressionengine tags you can spit out any amount of variable html on the fly.
hondo77
2004-05-14 10:29:18
In Defense of Templates

I disagree with the philosophy that tries to keep the "poor non-technical graphic designers" away from PHP...


I would argue that you can disagree because you are in the role of both engineer and designer so the line between the two is not just blurred, you can erase it whenever you want. In my experience, using something like Template Toolkit, which is a powerful template language but limited enough that it's not as powerful as Perl or PHP, is wonderful. As an engineer, I can just worry about serving up data. Designers, once they have been given the API to the data, aren't dependent on engineers for 99% of the things they need to do.


Then there is the issue of who is working on what. Relying on a single file to have your page code and your programming code leaves the door open to engineers and designers stepping on each other's work. Again, since you are in both roles it's not an issue for you--you have that luxury.


CD Baby is wonderful (I'll be placing another order next week) and, hopefully, you'll be getting bigger. You should be mindful that at some point you may be handing off development to a designer/engineer team. Since you are building from the ground up, keep in mind that future team. Is that future designer really going to want to wade through gnarly PHP programs? Is that engineer really going to want to deal with all that HTML and CSS?

yogimind
2004-05-14 14:46:05
agree + template/html building code size vs the html.
Some of this might be accomplished simply by linking to distinct style sheets per partner ala csszengarden.


Derek,


Everytime I tried to come up with a short concise way to 'generate' html it has always ended up syntactically to be a very similar number of key strokes. I eventually concluded why bother . . . just stick with the html and utilize style sheets.


I mean for example:
$div_plus_class = attribute($plaindiv, 'class', 'greeting')


vs.


?>

hello

My editor also closes tags for me nicely so its even shorter really. In the context of your table making function it seems to make a little more sense, but the function to modify the class attribute of the table seems to be more syntax then just modifying the original table code . . . Doesn't just pointing to a different style sheet make more sense? What am I missing?


Well your tenacity has produced useful things in the past so don't let me dim your light here. Just thinking this through with you.


-Yogi


PS I tend to agree with you on the programmer vs. designer territory thing. Any designer worth their salt that I've worked with knew how not to break the code and still get the effects they were seeking. I've seen very few cases where that strict decoupling has actually been required in my work. I mean as an example I was in love with the apache cocoon project at first, but then it really just turned out to be a hassle over some well managed jsp/php. For others 'your mileage may vary.'


yogimind
2004-05-14 14:51:53
busted links
Your links to your previous article seem specific to weblogger account holders. I get some bogus page telling me I'm not a weblog account holder.


The permalink seems to work previous article.

dereksivers
2004-05-14 15:46:40
busted links
Fixed! Thanks!
has01
2004-05-15 03:49:58
agree + template/html building code size vs the html.
"Everytime I tried to come up with a short concise way to 'generate' html it has always ended up syntactically to be a very similar number of key strokes. I eventually concluded why bother . . ."


This is a thought that bothers me too, and I'm still not sure the initial implementation work and added API complexity of an HTML generator is really worth it. I think to justify it you need to a. keep the syntax as tight as possible, and b. provide 'extra value' such as checking all tags, attributes and datatypes are valid based on a given DTD/schema. So who knows, maybe Derek or somebody else'll crack it yet; I think it's still worth some more investigation.


e.g. Donovan Preston's Nevow.Stan uses some of Python's 'magic method' trickery to get its S-expression-like syntax, which is a little more compact than the equivalent HTML. It provides type coercion and a degree of safety in that only valid HTML tags may be specified (doesn't enforce correct attributes though, afaik). Here's how Stan code looks:


tr[
td(width="40%", align="right", valign="top")[
b[element.description],
...
]
]


HTH

has01
2004-05-15 03:55:02
True, but there's more than one way to skin the cat...
"Why wrap a new language around something that [Language X] already does just fine?"


Absolutely! (See also Greenspun's Tenth Rule.) I realised this myself right after finishing my second homegrown templating system, which was a classic 'HTML-embedded mini-language' design (aka "crap DIY language implemented in not-so-crap commercial scripting language"). Doh!!!


So I canned the lot and started on #3, and haven't looked back since. My final solution was to remove ALL presentation logic from the HTML, which I've found an extremely satisfying solution. (Most templating systems only manage to separate out business logic.) I'm basically of the opinion that graphic designers shouldn't need to muck with any kind of programming at all, nor that programmers should have to mess around in HTML.


The trick is to take a plain HTML file and highlight those elements you want to manipulate from your code, then run it through a parser that converts it to a simplified DOM-like object model where each of those highlighted elements is an independent node that can be manipulated programmatically.


The resulting system is very simple and highly flexible and can handle both your "extreme examples" with ease, and should cope well with your other requirements (multi-look/multi-language templates, etc.). It's a pure templating engine (consisting of ~500 LOC and a public API of 3 classes and 14 methods) so has neither arbitrary HTML generation facilities nor any of the non-templating related convenience features that many "kitchen-sink" designs get loaded with - but that stuff rightly belongs in other modules anyway.


So while it's not exactly what you're looking for (see my other post for thoughts on HTML generators), I still think you might find it worth checking out.


HTH
[/shameless self-promotion;]

vrruiz
2004-05-25 20:28:20
Zope Templates
At last I see some light in the subject! I had the same experience with most template engines (and my own too). Weeks ago I noticed that someone is porting the Zope Page Templates to PHP, so we finally have a XHTML template engine, friendly with designers.