Top 5 php template engines
Why use a template engine?
Successful PHP applications and projects do not require a template engine. However, when a project starts to involve both programmers and designers, it is a good idea to separate application code from presentation. Another benefit of this model is with security/application updates.
Oscommerce is an open source shopping cart written in PHP. Presentation code is mixed with application code and as a result, most updates require manual code changes. This is because most people using this application customized the files that contain the presentation+application code. If it were separate, it would be easier to make the required updates and users would be more likely to make the changes.
The Engines
1) smarty
Features
- Output caching
- Multiple template sources: build them on the fly or load from a database
- Can be extended with your own functions and variable modifiers
- Output filters
- If, elseif, else statements
- Control flow statements, foreach
2) Prado
Prado is an event-based template language.
Features
- Configurable and pluggable modular architecture
- Feature-rich Web components: HTML input controls, validators, datagrid
- AJAX-enabled Web components
- Generic caching modules and selective output caching
- Security measures: cross-site script (XSS) prevention and cookie protection
3) phpHTMLLib
Features
- Layered approach to Application development
- Cacheable interface – cached pages, objects, widgets
- Notifies the programmer, which HTML tags are deprecated by the W3C
- PDO based cacheable queries
- Ajaxable pages, datalist, widgets
4) vlibTemplate
Features
- Includes a class that you can include called vlibTemplateDebug, which will output an HTML-formatted page with all data needed to see where you’re going wrong (great for debugging)
- Caches your templates to a file, which can speedup display time
- Built-in support for displaying database rows (supports: Mysql, Postgres, Informix, and Oracle)
5) php savant
Features
- Template scripts are written in PHP, so you don’t have to worry about permissions on a compiled directory
- The sourcecode of the savant template engine is well commented and designed, so it is easy to make additions
- The Template script is a regular PHP script, which allows you to use phpDocumentor to document it
- You don’t need to learn a new language or markup to create a template
14 comments
What about TinyButStrong? (http://www.tinybutstrong.com)
[...] Original post: Top 5 php template engines | A blend of programming and seo [...]
Dont forget the new kid on the block. h2o. It’s a great little library. It uses django formatting and works beautfully.
http://www.h2o-template.org/
PHP templating engines are a waste of time, just another unnecessary layer of abstraction!!! Even Rasmus (php’s creator) agrees with this, stating that php was already something close to a templating language. If you want a clean separation of business and display logic, just have some self control and put your view files into a separate directory.
Top 5 php template engines | A blend of programming and seo…
Successful PHP applications and projects do not require a template engine. However, when a project starts to involve both programmers and designers, it is a good idea to separate application code from presentation. Another benefit of this model is with…
[...] Top 5 php template engines [...]
Tony -> If you put your view files in a separate directory, you get nothing more, nothing less, but a template engine. It does not matter, whether the view files contain curly brackets or PHP statements, they are still templates and the layer that handles it is a template engine. And an enormous number of successful PHP applications uses some kind of template engine, even if it is not called “template engine”…
Zyx: no, just putting your views in a separate directory doesn’t make it a templating engine. If this were the case, every MVC framework could be called a templating engine (and I definately don’t see any MVC frameworks in this post). The point is that you shouldn’t have to learn and implement some other special templating language for your views.
I think the best strength of a templaing engine is that a developer can offer templating choices to users without giving them access to ANY logic. That additional layer of abstraction makes your server just a little more secure with very little additional effort on your part.
http://thietkexinh.com/TxTemplate/
Easy to use!
Yes, every MVC in PHP that follows this paradigm and puts view HTML code in a separate files **does** have a template engine. The definition suggested by you is a myth that has nothing to do with facts. Do you say that those views in the frameworks are executed by the higher powers and the script data self-assign to them without any help of any extra API?
Let’s follow your definition of a template engine and take a parser of external template language, for example from Smarty. To “change” such Zend_View into a template engine, you need approx. 10-30 lines of extra code: to check if the view has been modified and to run the external compiler. And what about Smarty 3? It will allow to write templates both in Smarty language and in pure PHP. How would you classify it? Half-template engine? How about Savant?
Of couse I do not say that Smarty is the best – in my opinion it is one of the worse template engines that shows, how **not** to make a template engine with an external language and the only advantage is that it is widely known. That’s why I’ve used it in my comparison. The general question of the discussion should be “whether an external language in template engines is good or bad thing”.
This list needs PHPTAL. It’s one of very few that protects against XSS and guarantees well-formed XHTML.
I just wanted to pitch in that I completely agree with the author’s assessment of osCommerce. I detest it as a platform and will do whatever I can to get customers off of it. One solution I’ve used effectively is UberCart with Drupal. It’s good for basic sites and anything I’ve seen done in osCommerce can easily be done it UberCart. And it separates the code from the design quite well.
Another technique I’ve used to allow designers to work with the PHP backend is to set up PHP to parse HTML files and then the designer can design whatever they like and PHP statement just need to be created to dill in content. I haven’t worked out all the kinks for doing a large site this way though
James
I’ve never tried uberCart. I will have to check it out.
Leave a Comment