Update:Archive/2.0/Developers/Templates

« Back to Archive | Update: Main

	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.

Templates

A template engine for the web should meet certain criteria.

http://wact.sourceforge.net/index.php/GoodTemplateSmells

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

Discussion

http://www.sitepoint.com/forums/showthread.php?threadid=123769

http://wact.sourceforge.net/index.php/TemplateView

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 -->
include('Smarty.class.php');
$smarty = new Smarty;
$smarty->assign('categories',
  array()
)

<!-- Sample Template -->
<div id="side">
  <ul id="nav">
  {section name=i loop=$categories}
    {if $categories[i].subcats[0]}
      <li><ul>
      {section name=j loop=$categories[i].subcats}
        <li><a href="showlist.php?category={$categories[i].subcats[j].catname}" 
               title="{$categories[i].subcats[j].catdesc}">
            {$categories[i].subcats[j].catname}</a></li>
      {/section}
      </ul></li>
    {else}
      <li><a href="showlist.php?category={$categories[i].catname}" 
             title="{$categories[i].catdesc}">{$categories[i].catname}</a></li>
    {/if}    
  {/section}
  </ul>
</div>

<!-- 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><ul>
      <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>
    </ul></li>
    <li><a href="showlist.php?category=Popular" title="Themes downloaded the most over the last week."><strong>Popular</strong></a></li>
  </ul>
</div>

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.