Well, maybe not. The situation today is fast moving from being a joke to a nuisance. Intergrating existing scripts is harder if they use different template engines; if you’re writing a library that outputs any (X)HTML you either tie it to a specific template engine, write renderers for many different systems, or forget about easy editing of the output at all and embed the (X)HTML.
Look at PEAR’s HTML_Quickform. It comes with *eight* different renderers. Now OK, they’re not all for specific template engines, but it gives an idea of the task involved.
If you do the design work, chances are you’ll work most of the time with one template syntax. Then a script is integrated into the website, and you’ve got another syntax to master, while the developer has to find a way to inject the output of the new script into the existing template (unless you want to maintain duplicate header/footer templates). The more scripts, the more the problem multiplies.
It’s also a lot of duplicate effort. “PHP Classes”:http://www.phpclasses.org/ lists “50 template engines”:http://www.phpclasses.org/browse/class/37.html at the time of writing; “PEAR”:http://pear.php.net list 5 template packages. Was there nothing else for these people to spend their time doing?
PHP needs a recommended template system. OK, maybe 2 systems (simple and advanced) with compatible syntaxes, so you can upgrade from the simple to the advanced with no problems.
Plus, if you’re a maximiser like myself, a recommended template engine saves the time wasted dithering over which system to use _(as I’ve been doing for my RSS Manager…)_ 
13 comments ↓
One way I tackle the problem you mentioned is to simply use the HTML_Quickform’s toHtml() method to capture the markup needed to display the form. Then you can assign it to the template system however you need to. If you use smarty templates, its just a matter of $smarty->assign(’myform’,$myform). Then your template can wrap the {$myform} variable in a named div, and the designer can assign css to it.
Smarty templates get my vote. They are very easy to implement and extend, there is plenty of documentation, and there is a vast community of helpful supporters.
Aye, Smarty would probably get my vote, even though I can see the benefits of the Zope-style XML attributes to mark up the templates (dummy content does make designing much easier).
I do use Smarty’s fetch/assign in this way - to use FormProcessor involves chaining the rendering agents together. But the time I tried to ‘wrap’ “Phorum”:http://www.phorum.org (and IIRC “phpBB”:http://www.phpbb.com also) into my Smarty template system it all went wrong - conflicting object names etc..
Completely agree. In fact the count is more that 50. I’d guess there are 100+ public domain (meaning Open Source / freeware etc) template engines out there in PHP.
Did a count once here: http://www.sitepoint.com/forums/showthread.php?threadid=123769 - hit over 80 I believe before losing count.
Even did a presentation once to PHP UG Switzerland - it’s online here: http://wact.sourceforge.net/presentations/200310_PHPUGCH/.
So why so many template engines? My guess is here: http://wact.sourceforge.net/presentations/200310_PHPUGCH/?page=4
What I hope is WACT’s page on the “Template View” http://wact.sf.net/index.php/TemplateView is helping people realise how old this subject is. What’s especially depressing as 95% of the template engines I’ve looked at do the following;
- Use custom template syntax e.g. {loop=MyLoop}Another template engine!{loop} (unsupported by basically any web page editor)
- Provide a “Pinhole API” for populating the template with data (e.g. $tpl->set(’var’,$value))
- Parsing the template at runtime (performance overhead)
You could almost write an abstraction layer for template engines (or a transformer).
As to the two engines PHP developers should standardize on, my votes go to;
1. PHP itself (see http://www.sitepoint.com/article/beyond-template-engine)
2. WACT (I’m biased) or similar where you can place tags like in your template, what are runtime components plus save a ton of HTML hacking. Basically learning from Java’s JSTL (without the imperative tags) or ASP.NET.
Smarty - http://smarty.php.net/ is PHP hosted which I count as a recommendation of sorts. It’s also one of the most popular PHP template engines around.
Hmmm - textile markup issues
That example from WACT
<calendar:month id=”MyCalendar” class=”CssCalendar”>
<calendar:day class=”CssCalendarDay” />
<calendar:dayselected class=”CssCalendarDaySelected” />
</calendar:month>
That in your template might correspond to a “component” you can work with from PHP like;
bc[php]. $Calendar = & $Page->getChild(’MyCalendar’); // ID attribute
$Calendar->registerEvents($EventsObject);
$Page->display();
Notice how populating “events” in the calendar means attaching them directly to the Calendar component as opposed on the “Pinhole API” of most PHP template engines (sorry - that includes Smarty).
The HTML output from the template uses HTML tag tags e.g. view-source://wact.sourceforge.net/examples/tags/calendar.php
In other words, you save yourself having to write alot of HTML plus you get a friendly API from your PHP script and “intelligent” components for solving particular problems (e.g a calendar component).
Course if that doesn’t make sense, how about this?
If you have an HTML anchor in your template like <a id=”MyLink1″ href=”http://www.mysql.com”>Click Here</a>
How do you change the value of the href attribute without inserting if/else logic into the template or something like href=”{link}”. In WACT if your template is
<a id=”MyLink1″ href=”http://www.mysql.com” runat=”server”>Click Here</a>
With the runat attibute, you can now modify the tag from PHP like;
bc[php]. $Link = & $Page->getChild(’MyLink’);
// Modify the attribute
$Link->setAttribute(’href’,'http://www.php.net’);
The template engine basically does the following steps;
1. Parse HTML (with PEAR::XML_HTMLSax)
2. Convert HTML to compile time objects (depending on the tag name, attributes etc.)
3. Compile time objects generate a unreadable but very fast PHP script which represents the template
[The above three steps only happen when you need to recompile the template - you changed it]
4. PHP script representing the template gets loaded by your PHP script - it creates a lightweight tree of runtime components you can interact with (like the Calendar component up there)
Anyway - ranting
Nuff already.
Good point, though with that title I was expected you would point out that *PHP is itself a template engine*, making the proliferation of PHP-based engines all the more humorous. Converting a well-documented syntax into one that is comparably complex yet more arcane seems to be the result in too many cases. How unfortunate for users.
Heh, that’s funny. And I was just writing my own template engine
Well, I won’t let that stop me…
Of course the most amusing thing is PHP started out as a templating engine.
Of the 50 listed at PHP classes, most of them are just variations of other famous template engines, with added functionality.
If you want to use a good, widely-adopted one, use “smarty”:http://smarty.php.net
XSLT is a W3C standard, let’s just use that.
I do, and I like it a lot. I’ve written about it ["here":http://www.manuzhai.nl/weblog/comments/the-power-of-xslt/].
For me, PHP is the only ‘template engine’ I need
http://poorbuthappy.com/ease/archives/002648.html
Peter Bowyer’s weblog: Template engines:- PHP’s biggest joke: “PHP needs a recommended template system.” It sure does….
hey guys, I seen a lot of people talking about IMDemons and I wondered if any of you have it yet? I seen a good review on http://daxaurand.com and he said it looks fantastic. Please share your thoughts…
Leave a Comment