Discovering what life is about

Simple and Easy Template Engine with PHP

Simple and Easy Template Engine with PHP

 

Template engines are a "good thing" but the vast majority of template engines may simply have it wrong. The one exception to this rule would be Smarty, although it's simply too big, and  pretty pointless.

 

This article discusses template theory. We’ll see why most "template engines" are overkill, and finally, we’ll review a lightweight, lightning fast alternative.

 

 


 

 

Template Engine Basics

Basically, template engines utilize a scripting language (PHP) written in C. Inside this embedded scripting language, you have another pseudo-scripting language (whatever tags your template engine supports). Some offer simple variable interpolation and loops. Others offer conditionals and nested loops. Still others (Smarty, at least) offer an interface into a large subset of PHP, as well as a caching layer.

Why do I think Smarty is closest to right? Because Smarty's goal is "the separation of business logic from presentation," not "the separation of PHP code from HTML code." While this seems like a small distinction, it is one that's very important. The ultimate goal of any template engine shouldn't really be to remove all logic from HTML. It should be to separate presentation logic from business logic.

There are plenty of cases where you simply need logic to display your data correctly. For instance, say your business logic is to retrieve a list of users in your database. Your presentation logic would be to display the user list in 3 columns. It would be silly to modify the user list function to return 3 arrays. After all, this function shouldn't be concerned with what's going to happen to the data. Yet, without some sort of logic in your template file, that's exactly what you’d have to do.

While Smarty gets it right in that sense (allowing you to harness pretty much every aspect of PHP), there are still some problems. Basically, it just provides an interface to PHP with new syntax. Stated like that, it seems sort of silly. Is it actually simpler to write {foreach --args} than ? If you do think it's simpler, ask yourself whether it’s so much simpler that you can see real value in including a huge template library to achieve that separation. Granted, Smarty offers many other great features, but it seems like the same benefits could be gained without the huge overhead involved in including the Smarty class libraries.

 

 


 

 

An Alternative Solution

The solution I'm basically advocating is a "template engine" that uses PHP code as its native scripting language. I know this has been done before. And when I first read about it, I thought, "What's the point?" However, after I examined my co-worker's argument and implemented a template system that used straight PHP code, yet still achieved the ultimate goal of separation of business logic from presentation logic (and in around 25 lines of code, not including comments), I realized the advantages.

This system provides developers like us access to a wealth of PHP core functions we can use to format output – tasks like date formatting should be handled in the template. Also, as the templates are all straight PHP files, byte-code caching programs like Zend Performance Suite [6] and PHP Accelerator [7], the templates can be automatically cached (thus, they don't have to be re-interpreted each time they’re accessed). This is only an advantage if you remember to name your template files such that these programs can recognize them as PHP files (usually, you simply need to make sure they have a .php extension).

While I think this method is far superior to typical template engines, there are of course some issues. The most obvious argument against such a system is that PHP code is too complex, and that designers shouldn't have to learn PHP. In fact, PHP code is just as simple as (if not simpler than) the syntax of the more advanced template engines such as Smarty. Also, designers can use PHP short-hand like this . Is that any more complex than {$var}? Sure, it's a few characters longer, but if you can get used to it, you gain all the power of PHP without the overhead involved in parsing a template file.

Second, and perhaps more importantly, there is no inherent security in a PHP-based template. Smarty offers the option to completely disable PHP code in template files. It allows developers to restrict the functions and variables to which the template has access. This is not an issue if you don't have malicious designers. However, if you allow external users to upload or modify templates, the PHP-based solution I presented here provides absolutely no security! Any code could be put into the template and run. Yes, even a print_r($GLOBALS) (which would give the malicious user access to every variable in the script)!

That said, of the projects I've worked with personally and professionally, most did not allow end-users to modify or upload templates. As such, this was not an issue. So now, let's move on to the code.

 


 

Ref : http://articles.sitepoint.com/print/beyond-template-engine

 

Ref : http://www.massassi.com/php/articles/template_engines/

 

 

doc/20100221125906_template.zip

 

doc/20100221125917_bTemplate_0.3.zip

 






Model–View–Controller (MVC) is an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each.

 

The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can refresh.

 

Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Also, the ActiveRecord is an accepted design pattern which merges domain logic and data access code - a model which knows how to persist itself.

 

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

 

The controller receives input and initiates a response by making calls on model objects.

 

 

An MVC application may be a collection of model/view/controller triplets, each responsible for a different UI element.

 

MVC is often seen in web applications where
the view is the HTML or XHTML generated by the app.
The controller receives GET or POST input and decides what to do with it, handing over
to domain objects (i.e. the model) that contain the business rules and know how to carry out specific tasks such as processing a new subscription.


view : .tpl files

model : logic .php files

controller : index.php



Simple and Easy Template Engine with PHP


---
Categories : Online business    Themes : Tools Design
Share |
add a comment...

0 Comment

Leave a Comment