From MozillaWiki
Jump to: navigation, search

« Back to Archive | Update: Main

Ambox outdated.png THIS PAGE MAY BE OUTDATED
This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.


A template engine for the web should meet certain criteria.


  1. Pass the Dreamweaver test.
  2. Simplicity.
  3. Validating.
  4. Cacheable.
  5. Self-Inspecting.
  6. Secure.
  7. Flexibility.

Templating Engines for Consideration

  1. PHP (yep PHP itself is a template engine)
  2. Smarty
  3. XSLT - technically XSLT is also a template engine
  4. PEAR::HTML_Template_Flexy
  5. PEAR::HTML_Template_IT
  6. PEAR::HTML_Template_PHPLIB
  7. PEAR::HTML_Template_Sigma
  8. PEAR::HTML_Template_Xipe
  9. patTemplate
  10. PHPTAL (port of Zope templates)
  11. PHP Savant - reclaiming PHP
  12. SimpleT - also reclaiming PHP
  13. YATS - Yet Another PHP Templating System
  14. YAPTER (yet another yet another?)
  15. Virtual Template (French)
  16. PHPLib
  17. ETS - Easy Template System
  18. AvantTemplate
  19. XTemplate
  20. htmltmpl
  21. Bleetz
  22. ASAPlate
  23. DTE
  24. Enzyme Template (part of a mini framework)
  25. PHP-Service
  26. Quick Template
  27. Sledgehammer
  28. PHPMarker
  29. TPLN
  30. FT
  31. ATemplate
  32. ctlTpl
  33. hierarchy template
  34. InTemplate
  35. lorenphplib_patternizer
  36. MyTemplate
  37. Path Wrapper
  38. phpoot
  39. Smart Template
  40. Templato
  41. phpBB template engine
  42. Fast Template
  43. FastTemplate Clone - drop in replacement for FastTemplate.
  44. Tiny But Strong
  45. Simple Turtle Template
  46. MiniTemplator
  47. TagTemplate
  48. Template Power
  49. vLibTemplate
  50. Richard Hayes Template class
  51. Bugi Template (site is down? hotscripts entry)
  52. bTemplate
  53. Phemplate
  54. Templeet
  55. eZ Publish 2.x Templates
  56. eZ Publish 3.x Templates - very different to 2.x
  57. TemplatePower
  58. Muze Template
  59. Logic Template - not sure about this one - seems to be about turning PHP into an intepreter
  60. varpage (formerly known as ShellPage)]
  61. PHP-DOM extension (HTML support)
  62. Template-X
  63. KTemplate (former Apolda Template)
  64. EZ Template
  65. 4Arrow Template Compiler
  66. dutchtpl
  67. Xaraya - implements it's own template engine
  68. ecTemplate
  69. Freetemplate
  70. ModelIxe
  71. PHPTempt
  72. Server Side Template Parser
  73. Vanilla Object Oriented Templates
  74. vBulletin - has it's own template langauge
  75. ExTemplates
  76. TemplateTamer




morgamic's take

A solid application structure could eliminate the need for a comprehensive templating engine. Wrapping HTML output is a relatively simple task done by using includes in parallel with proper use of CSS. I always question templating that extends beyond that in terms of complexity.

As with PEAR::DB or adodb, I think the use of a templating engine should only be considered if it is the right thing to do.

That said, I question whether adding the layer of complexity and adding another dependency is really necessary if we can use CSS for all of our presentation.

Don't get me wrong -- I'd definitely like to se HTML wrapped in functions where appropriate and a good segregation of PHP and HTML in order to have some sort of uniformity and structure when it comes to each .php script. I think that is a great goal and should definitely be realized in any good application.

But if we can use CSS properly, all HTML output will be exactly the same with the exception of DOM identifiers when appropriate, using templating or skinning the whole app should be reduced to a matter of switching stylesheets. From there, it's just a matter of packaging your markup properly, which is not something I see us needing a separate tool for.

mvl's comments: A template engine is definitly worth it. It is not about CSS. It is about readable code. html all over the php code makes the php unreadable. php all over the html code makes the html unreadable. You really want to split it. (and having it split up reduces the risk of cvs conflicts) --Mvl 10:51, 22 Jan 2005 (PST)
morgamic's comments: I think I may have not been thinking enough about the people responsible for UMO's design. The need for a good engine that can accomodate them and allow them the ability to change look and feel without mucking with CVS would be a great feature -- mconner helped explain that to me. UMO will be very different from Bouncer in that respect, so maybe I have to read up more on templating engines.  :)

alanjstr's take

We definitely need to move from having the html all over the php. I don't think anyone will disagree with that. Templating allows us to separate the data from the presentation. I'm all for using CSS. But the html it applies to is what we need to work on.

The sidebar is an example. We have different kinds of sidebars. We have one for themes, one for extensions, one for developers ... Instead of us making a whole sidebar module that does echos, we can use a template that accepts data and turns it into presentation. Consider this example I wrote using Smarty

<!-- Incomplete PHP Wrapper -->
$smarty = new Smarty;
<!-- Sample Template -->
<div id="side">
  <ul id="nav">
  {section name=i loop=$categories}
    {if $categories[i].subcats[0]}
      {section name=j loop=$categories[i].subcats}
        <li><a href="showlist.php?category={$categories[i].subcats[j].catname}" 
      <li><a href="showlist.php?category={$categories[i].catname}" 
<!-- Sample Output -->
<div id="side">
  <ul id="nav">
    <li><a href="showlist.php?acategory=All" title="Show All Themes Alphabetically">All Themes</a></li>
      <li><a href="showlist.php?category=Animals" title="Animal Themes">Animals</a></li>
      <li><a href="showlist.php?category=Compact" title="Small icons">Compact</a></li>
    <li><a href="showlist.php?category=Popular" title="Themes downloaded the most over the last week."><strong>Popular</strong></a></li>

All we do is pass in an array of data, and the template determines how to present it. We don't clutter our code with echo statements.

Colin's take

One thing most people seem to be agreed on is that it is best to extract the HTML code from within the PHP code, as it becomes unmanagable after a while. The problem is then which templating engine to use... certainly the ones I have had a quick glance at on the list above, they tend to seem to work by passing them a data-structure (Array usually) which they can then do something with.

The "standard" seems to be Smarty, and I've taken a look at HTMLTMPL too and they seem to operate in the same way, it would be just a matter of deciding which was most suitable... I don't have an opinion on that, but I do think templating is the way to go.