Bad Template Smells

Many of these are merely the opposite of the Good Template Smells. (left here to support the discussion below)

Duplication - Templates should make the presentation of the application easier to change. If the templates have alot of duplication in them, then some changes will be difficult to make. Template Engines should support methods of eliminating duplication. This may conflict with other GoodTemplateSmells.
Compiling at runtime - If the template is not native (PHP), compiling it at runtime will introduce significant and unnecessary lag. Templates will only change occasionally so between changes should be compiled into the fastest executable form (i.e. native PHP) possible. Please Note: Just because a template engine claims to compile to native PHP does not guarantee that it will be faster. As an example, the Smarty template class, which compiles to native PHP, requires that their very large library be loaded on each page view. If you don’t have some sort of byte-code caching mechanism (like zend or phpAccelerator), the overhead of this library makes it slower than many run-time interpreted template classes. Benchmark your typical uses before deciding on a template class!
Custom template syntax - Introduces (unnecessary) complexity to application. Places burden on users to learn syntax. Issues with debugging, profiling etc. Not widely supported (by common page design tools like Dreamweaver).
Control Structures in Template - Suits programmers not web page designers.
Claims to seperate code from HTML - Seperating View from Controller and Model, which is an application design issue, is often confused with making life easier for web page designers, by removing the programming language from the template. But a View (presentation *logic*) has to contain some logic, either explicitly declared or disguised (in XML tree). Typically claims of this nature mean some additional template programming language has been implemented - see point 3 (custom template syntax).
Exhaustive binding logic - Developers required to make significant effort writing code which “binds” the Model to the View.

Claims to separate code from HTML: Beg to differ

It is possible to have code separated from html (and it is a good idea). If in your template you only use markers for begin and ends of templates, and free variables, and you control such template by providing data tree to the template engine, you do have separated html and code. Such approach can be ilustrated by Template Tamer.

Re: Claims to separate code from HTML: Beg to differ Think we need to be careful about definitions here. Template Tamer uses a declarative syntax of the comment style (as discussed in the TemplateView page). There is still logic in the template but it’s not imperative. For example from the Template Tamer wiki on SimpleMySQLRowList the template looks like;

 <html>
 <body>
 	<h1>MySQL Row list example</h1>
 	<table width=256>
 	<!--NAME:ONEITEM -->
 		<tr bgcolor="white">
 		{NAME}: {PRICE}
 		</tr>
 	<!--END:ONEITEM -->
 	</table>
 </body>
 </html>

This is logically equivalent to (using PHP);

 <html>
 <body>
 	<h1>MySQL Row list example</h1>
 	<table width=256>
<?php
            while ($row = @mysql_fetch_array($sql_result, MYSQL_ASSOC)) {
?>
 		<tr bgcolor="white">
 		<?php echo ( $row['name'] );?> : <?php echo ( $row['price'] );?>
 		</tr>
<?php
            }
?>
 	</table>
 </body>
 </html>

The point is you cannot escape having some kind of logic in the Template View (that logic being called Presentation Logic). If I see the claim “seperates code from HTML” I’m instantly on alert - it suggests the template developers motivation was simply to remove PHP code from the template rather than attempting to achieve the MVC seperation of View from Model. If the claim was “allows presentation logic to be seperated application logic” or “allows seperation of View from Model” then I’m happy.

Re:Re: Claims to separate code from HTML: Beg to differ

Sorry, but above examples are equivalent only in the terms that they produce the same result. The first example has 2 files (you have shown only one), and the second only one. The second example has while expression loop inside template which is code, while the first one does not contain loops, if’s or any other control structures, just markup, or as you say declarations. That is by no means programming code, since it describes only static properties, not modeling dynamic ones. If one would consider <!–NAME:XX–> to form programming language, than the same thing could be said of html, xml. But they are not called programming languages, they are called markup languages for the reason. In the same way <sometag> and </sometag> are only markup and not the code, the <!–NAME:XX–> and <!–END:XX–> are also only markup. Markup defines static properties, while programming code models dynamic behaviour.

If I and friend designer were doing this example together, in the first case we would agree on the names of the templates, and after that I would be only changing the logic file, and he would be changing the html template. In the second example, logic and html are in the same file, and we would be constantly conflicting each other in it.

Maybe missunderstanding is that some people have impression that when I say “that it is possible to have code separated from html”, is that I am saying thet there is no relation or contract between the two. This is of course impossible, and some contract must exist. My stance is that this contract should be kept to bare minimum, and that it should not describe dynamic properties like whiles, ifs, selects, whatever, i.e. it should not contain programming code, but merly markup of the parts.

And that is possible, and I believe a “good thing” to do. Still I can see that other people like some other approach. I just say that it is possible for me, and that I see a very good use of it.

I believe that template system purpose is to separate html from code, not to separate presentation logic from model logic. I *do* recommend separating presentation from model, but I find stuffing all presentation code into the template a messy thing to do. Actually when I hear that Template system should hold all presentation logic I get into the alert state :) . I usually refer to the templates whit just markup as ThinTemplate or “clean template”, and templates with stuffed whole presentation logic inside of them as “FatTemplate” or “dirty template”.

For me, model is model, and view consists of resource (template) and code that drives it. Resource (template) is just data describing the appearance, and should contain only markers and no programming code. And code for the view should be fine pure php separated from the resource. This is also the way languages which have MVC and MVP built in from the start for years (like Dolphin Smalltalk)are dealing with it.

As reference, here is my previously written wiki page on how to use MVC with TemplateTamer –rush

Re:Re: Claims to separate code from HTML: Beg to differ

Another thing to consider is your target user/project. If you’re developing a CMS for a news organization, the idea that templates remain fairly static for long periods of time may not be true.

As a developer I want to empower my users to make as many presentation logic changes as they want, so that the presentation and content match their goals of delivering news and information in a timely manner.

However, if you’re developing a corporate site that’s fairly static, then a system where a developer is managing presentation logic, and a designer merely worries about the look/feel in a thin template may be more appropriate.

–chris