Erich Schubert is talking about web templating languages. He’s looking for a pure-XML templating solution, but that might not be necessary for simple web-page design, where we don’t need all the extra benefits of heavy-duty transformation standards like XSLT.
Keeping it simple
For PHP-driven web sites, I’m a big fan of Smarty, which uses braces (“{” and “}”) to delimit template constructions. Braces have no special meaning to XML parsers (they’re just character data), so it’s possible to put a template expression inside an attribute value (for example), while keeping the template itself as well-formed XML and not requiring the elaborate paraphrastic expressions you need to set up attribute values in XSLT:
<p id="x-{$myvalue|escape}">Hello, world!</p>
Concurrent markup resurrected
Really, Smarty adds a second set of concurrent markup on top of the XHTML. Smarty constructs don’t have to balance with XML element boundaries, and with only a little care, I’ve never ended up with a Smarty template that wasn’t well-formed. JSP’s mistake was using something that looks like XML but isn’t quite, messing up parsers. Even the old SGML CONCUR feature would not have allowed markup inside attribute values. Sometimes there’s something to be said for using two different syntaxes when you’re trying to represent two different things.
Quoderat 
“where we don’t need all the extra benefits of heavy-duty transformation standards like XSLT”
What’s your feeling on XML based templating languages like Kid and Genshi? They try to preserve the simplicity of text based template languages but generate infoset (are we still using that term?) instead of text providing some of the benefits of XSLT.
I’d be interested to hear your take on the general concept as I’ve received mixed opinions from people who I’d consider to be highly knowledgeable about XML.
Smarty? How about PHP? Smarty is about 80% as hard to learn as PHP, and PHP can do anything Smarty can. Why learn both?
If Smarty is chosen, then at this rate it will become a full-blown programming language like PHP did, and people will be clammering for a new templating language to use over Smarty. It will never end.
Mark:
I use straight PHP for trival web sites (just a few pages), but I do find myself reverting back to MVC for larger sites to keep maintenance easy. I know that it’s possible to use PHP in an MVC way, but I prefer Smarty for the templates because (a) it’s simpler and shorter, and (b) it allows my templates to be well-formed XML and be edited and syntax-checked by XML tools (I know that ‘b’ won’t matter to most developers, but it’s big for me). Smarty is considerably simpler than PHP even if you use all the features, but in an MVC approach, I keep as much logic as possible out of my templates (I stick to value insertion, looping, and very rare display-oriented conditionals), and it takes, maybe, 15 minutes to learn those parts of Smarty.
Finally, on a purely subjective level, I find
<a href="{$url|escape}">link</a>considerably more pleasant than
but I recognize that that’s purely a matter of taste.
What’s the problem with attribute values in XSLT?
http://www.w3.org/TR/xslt#attribute-value-templates
That covers me for most of my use-cases, and it’s only occasionally that I have to use .
Sorry, that should have read <xsl:attribute/>, but it got stripped out.
James:
There’s nothing wrong with xsl:attribute, except that it’s even more verbose than the Smarty or straight-PHP options. On the bright side, it’s guaranteed to be well-formed (the PHP example cannot be well-formed XML, and the Smarty example can be, but is not guaranteed to be).
On a separate note, xsl:attribute is one place that XSLT does a poorer job than Smarty of helping the author write a template that will produce well-formed XML. If I’m editing a Smarty template in an XML editor, this would cause a well-formedness error in the editor itself, at design time:
<foo bar="{$a}" bar="{$b}"/>This, on the other hand, would be caught only during actual XSLT processing at test or production time, because the template itself is still well-formed XML even though the output document will not be:
In other areas, though, XSLT does a better job of enforcing well-formedness on the output document, and I certainly prefer it for general purpose XML templating (vs. simply web pages in a web app).
David, thanks for clarifying. I wasn’t thinking about the problems faced by an author; just that XSLT does support a similar syntax and that you don’t need to use
most of the time:which can be used for the majority of my use cases (and XSLT 2.0 with XPath 2.0 probably deals with the occasions when I did need to use
.btw, it would be good to have a link describing how to insert markup into your comments system, or maybe support comment preview? I’ve tried three different ways (this will be the fourth) and still haven’t worked it out, but then maybe I’m just lucky like that! Other WordPress installations tend to state which XHTML elements are permitted and there is a commented out bit in this page source, but the tags mentioned there doesn’t seem to apply (at least, the
seems to have the character data completely removed).James: just type straight HTML into the comments. The code element in HTML just changes the typeface; it doesn’t escape anything. If you want to include markup, you’ll also have to escape special characters (like
<and&) using entities. For example, to write this:you’ll have to type this
(Most people would also escape the
>with>just for good measure.)Cheers, trying again. The XSLT example of attribute value templates that I was trying to insert looked something like this:
<foo a=”{//a}” b=”http://{$host}/{$path}” />
but I appreciate that tooling for this falls a little short of what would be desired; i.e. invalid markup only gets found out at runtime, or if you’re thorough, during your automated tests.