Template System Techniques

[G.Schuster]

One question to the php-purists - how do you handle pure-php templates uploaded by users?
As most template engines support only a specified subset of what PHP offers it's relatively easy to deny the use of e.g. <?php unlink(...); ?> in a template - but how would you handle this in pure-php templates?
As far as I can see you'd have to parse the code, check each and every function call and again limit it to a specified subset that seems OK.

Just to make sure no one gets me wrong - I'm using both pure-php and Smarty, each one as it fits.
The question above should be no offence, I'm really interessted in a solution to solve the mentioned problem as I'd like to write a "pure-php template system" for one of my apps that handles cahcing etc. but lets the templates be pure-php.

[F.Danials]

It would be presumptuous to claim that Smarty is useless. Template engines like Smarty are definitely useful in certain cases. For example, if you want your site users to upload their own template there is no way you ever let them use PHP.

For the rest of the cases, it’s matter of preference and opinion. Sure, if you like Smarty use it. If you think native templating is the way to go and smarty is not worth it, you are welcome to do so. On the other hand, if you keep ramming your opinions down others throat and claim to know one ‘true’ way of software engineering, you come off as rather immature. Someone who has just picked up a programming language and is so obsessed with it that he denies the existence of everything else.

Take it easy! just move on..

Well said mate!
In my opinion, template engines are useful and they do speed up development, else why would so many people wish to use them.

I quickly done a Google search for "Native Templating", and the first result returned was a Google Book preview. Straight away is was stated that "approaching large PHP projects using templating makes sense"

The same argument about templating can be could be said for frameworks also, website can be created without frameworks, so again is there much need for them?

Of course there is, as again it helps speed up development. Sure there is some overhead, a developer first needs to put together the framework, buy once done, the advantages are huge!!!

[imaginethis]

One question to the php-purists - how do you handle pure-php templates uploaded by users?
As most template engines support only a specified subset of what PHP offers it's relatively easy to deny the use of e.g. <?php unlink(...); ?> in a template - but how would you handle this in pure-php templates?
As far as I can see you'd have to parse the code, check each and every function call and again limit it to a specified subset that seems OK.

Just to make sure no one gets me wrong - I'm using both pure-php and Smarty, each one as it fits.
The question above should be no offence, I'm really interessted in a solution to solve the mentioned problem as I'd like to write a "pure-php template system" for one of my apps that handles cahcing etc. but lets the templates be pure-php.

I guess if a project required user uploaded templates I might see the purpose in using a minimal template engine, though I would probably go with an XML based template for simplicities sake.

Well said mate!
In my opinion, template engines are useful and they do speed up development, else why would so many people wish to use them.

Exactly how creating a template engine speed up development?

I quickly done a Google search for "Native Templating", and the first result returned was a Google Book preview. Straight away is was stated that "approaching large PHP projects using templating makes sense"

I read over the section that you highleted from the book and here are some flaws

The first and most obvious problem is that your using a very powerful language (PHP) to do very simple job (spitting out content). The problem is not a performance issue, though. It's simply that by using PHP to take care of the content rendering you are introducing yet another point in your project where things can go wrong.

Even with a template engine you still have the potential for error. Using a template engine does not reduce the possibility for error you increase it.

Think of the common problems you face when writing big classes -- typographical errors, misspelling variable names, accidentally reusing counter variables in heavily nested for loops. All these problems are just as constant if you also use PHP for your templating.

Typographical errors, misspelling variables these are still problems in template engines. In fact, template engines generally make it harder to find simple errors like these. Most developers/programmers use some sort of syntax highlighting agent which help to point out simple errors. Simple errors like these cannot be so simply averted using a template engine. {} and [] don't have the same meaning in <?php ?> or <? ?>.

The second and perhaps more serious problem, becomes obvious when you consider large projects. One of the big advantages of using MVC in PHP projects is that the view and the controller can be delegated to developers skilled in the art of design and HTML, but but possibly not so skilled with PHP. THis allows the more expensive software architects to work on the heavy-duty PHP driving the model of the model of the project, and the less expensive Web developers to work on the interface.

I totally agree. However, if they are working as a website developer and use PHP, they should know how to use PHP. So if they see well formatted PHP code, the should have a probelm.

However if you chose to use PHP templating, then the Web developers have no choice but to write in PHP. Admittedly there's not much PHP they need to know. It's the kind of PHP that could easily go on a cheat sheet.

They made my point for me

The problem is not so much one of a learning curve but rather one of danger. PHP, after all does not restrict what these developers may or may not use in there templates. Rather, they must restrict themselves. Infinite loops, dangerous system calls, and other potentially critical mistakes are just a tiny typographical error away.

AH! Finally a reason that I can accept. However, developers can make the same errors in the model as well. In fact its more likely that they will make dangerous system calls within the model than within the template. So should we create a new language on top of PHP that removes those dangerous system calls or typographical errors? o.o

If there were some way to allow web developers to render the out put of a page using flexible tags as part of an arbitrary language, rather than using PHP, this problem could easily be negated.

Er... Rather than using PHP is a little misleading. You haven't stopped using PHP by using a template engine. It's still there... running your template engine. I don't understand why its necessary to get away from PHP? A template engine in PHP would merely act as a wrapper for existing PHP capabilities. So unless the template engine is actually doing something better than it can be done in PHP, I would default to using PHP

The same argument about templating can be could be said for frameworks also, website can be created without frameworks, so again is there much need for them?

Of course there is, as again it helps speed up development. Sure there is some overhead, a developer first needs to put together the framework, buy once done, the advantages are huge!!!

Honestly, if a template engine helps you develop faster thats great, however I don't see how it does. A template engine is 1 extra thing that will need to be debugged. 1 extra potential for bottlenecks. 1 more language to be learned. Smarty has some nice features out of the box. Yes, they may make a few things simply with a few of there functions. But I can still get the same functionality by opening up it's php files ripping the function out, stripping it of its Smarty-ness and wallah PHP function in PHP. Now, if Smarty were written in C or C++ this would be a completely different story. But its written in PHP, which has all the capabilities of Smarty and then some.

I hope this time I didn't offend someone and if I did I apologize. >.>

[Cups]

One question to the php-purists - how do you handle pure-php templates uploaded by users?
As most template engines support only a specified subset of what PHP offers it's relatively easy to deny the use of e.g. <?php unlink(...); ?> in a template - but how would you handle this in pure-php templates?

My first thought was to use the black-list approach of denying those functions - as you can do in php.ini.

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
disable_functions = "unlink, exec"

If that works with ini_set() - later - doh, "php.ini only", no it doesn't.

(unless there is some magic way of ini file swopping ... )

But in practice maintaining a white-list of functions you do allow would be safer and more practical.

Even if it takes a long time to parse that template on upload, you'd only be doing it once wouldn't you? That sounds interesting.

While we are on the subject of templates, did anyone else see this post by Ren in the other place, and if so what did you make of it?

[Stormrider]

Interesting idea with the named entities, but I think there is a big potential for clashes with the already defined ones.

The best templating system I have used is xtpl - simply because it is so simple, hardly any bloat, just replaces values in a template file and perhaps performs some limited caching.

I haven't found much of a use for a templating system though, I'd still rather use php.

[Cups]

I haven't found much of a use for a templating system though, I'd still rather use php.

Ditto. I went through a stage of using them, and tried several and at the time I couldn't understand the point of them.

I still don't, and I put that down to my own ignorance really - that and not working in a team where there are programmers and designers.

[Stormrider]

I work in a team with a designer, but he is picking up simple php pretty easily, it hasn't really been a barrier.

[imaginethis]

I think it would be interesting if someone actually made a template engine but wrote it in C rather than writing it in PHP... hmmm >.>

[F.Danials]

Why?

I thought Template Engines were a waste of time, what would be the advantage of writing it in C if there is no need for them in the first place?

[prince_mallow]

if you don't feel like ever using a template system again read this. most importantly the posts by voostind

The use I see is not having to type out the company name out when you install a cms it just copies it everywhere... but for real programmers... ??

[simshaun]

Like many have said, just stick with plain PHP rather than having a template system that uses custom syntax. I once tried a 3rd party templating system (much like Smarty). I'll never use one again.

Use a good framework, such as CodeIgniter (a.k.a. CI, low learning curve, great docs, great overall) or Zend (high learning curve, enterprise level, great overall).

Since I've got more experience with CodeIgniter than I do Zend, I'll talk about it and how it works much like a templating system (minus the custom syntax... but you have the option to use it if you want).

CI follows (closer than most frameworks I've seen) the MVC (Model-View-Controller) design pattern. Essentially, your models interact with the database, your views are your templates, and your controllers are where all your business logic goes.

Here's a simplified example for a "template"-like implementation for viewing a blog article in CodeIgniter. Note that in this example I'm not using headers or footers simply for the sake of understanding this more easily. Also, I don't advise using short tags, but in this example I am for the same reason I'm not using headers or footers.

Your view (views/blog_article.php) might consist of

<html>
<head>
<title><?=$page_title?></title>
</head>
<body>
    <h1><?=$page_headline?></h1>
    <?=$article_content?>
</body>
</html>

Your model (models/Blogmodel.php) might consist of

class Blogmodel extends Model {

    function Blogmodel()
    {
        // Call the Model constructor
        parent::Model();
    }

    function get_article($article_id)
    {
        $this->db->where('article_id', $article_id);
        $query = $this->db->get('articles');

        if (!$query->num_rows()){
            return FALSE;
        }
        
        return $query->result();
    }

} 

And your controller (controllers/Blog.php) might consist of

class Blog extends Controller {

    function index()
    {
        // Not used in this example.
    }

    function article($article_id)
    {
        $this->load->model('Blogmodel');
        $article    = $this->Blogmodel->get_article($article_id);

        // Make sure the article exists.
        if ($article === FALSE){
            show_error("The article doesn't exist.");
        }

        $data['page_title']      = htmlentities($article->title); // becomes $page_title in your view
        $data['page_headline']   = htmlentities($article->title); // becomes $page_headline in your view
        $data['article_content'] = $article->article;             // becomes $article_content in your view.
                                                                    //     - there ought to be no need for htmlentities
        
        $this->load->view('blog_article', $data);
    }
} 

(Assuming we're using a server on localhost):

• http://localhost/blog/article/51 loads your Blog controller's article(51) method.
• Blog controller calls get_article(51) in the Blog model.
• Blog model returns article 51's row from the database.
• Blog controller takes bits of article 51's row and puts them into the $data array.
• Blog controller loads the blog_article view and injects the $data array into it, using its keys as variable names.
• The blog_article view is shown on your screen with the data.

Easy enough to follow?

[ramupl]

Basically, I have been using PHP as a templating engine for quite some time now.

And I am really starting to see light in creating a custom Template Engine to speed up template creation and ensure that standard PHP code gets generated every time.

e.g.

{name?}

would generate

<?php if (!empty($name)) echo $name; else echo '&nbsp;' ?>

the engine should have 2 modes - development and production.
In development mode, it should always compile the raw template into PHP and in production mode it should only use the PHP template and never compile. with the option to define locations for uncompiled and compiled templates.

Also it should support custom function definition so that you can shorten commonly written code into simpler tags

e.g.

{show_tags}

would generate:

<?php if ( is_array($tags) { foreach($tags as $tag) { echo '<div class="tag">'.$tag.'</div>'; } } else { echo '<div class="notag">No tags defined</div>'; } ?>


Smarty fits the bill but I am more impressed with Sintags of the Akelos framework.

[simshaun]

Just checked out sintags, and seems like a good idea. The problem for me is that is still involves learning another syntax that doesn't facilitate making the entire application easy.

[Superman859]

I find this all pretty interesting as a while back I was looking into creating my first template myself. I have heard of Smarty but never looked into it.

Much of this templating discussion is above my head as it seems the systems being discussed are much more than what I needed for my site. I wasn't interested in user customizable templates or anything like that, and simply wanted a template for my website that pulled data from a database.

It was straightforward in PHP without any issues and the code is clearly readable in my mind. Each page file is roughly

<?php
include "common.php";
$page = new WebPage("pagename");
 
include "template.php";
?>

and template.php was coded as HTML and then I simply pulled the page specific data out and replaced it with some PHP statements using my $page object. Simple.

Perhaps if things got more difficult or I was trying to make some crazy hard template it might make more sense to look into third party template systems, but I don't see any point at all for a basic template.

And all this discussion on short-hand notation and how it makes a big difference or code much longer doesn't really make much sense to me either.

To me, there is little difference in

<?=

and

<?php echo

In all honesty, most of us on this forum can type pretty fast and we can type either statement in about one second regardless. Both are readable to me, but I prefer longhand notation because I think it's probably more readable to other people.

[simshaun]

The difference in short notation and long is that some servers dont have short_tags turned on.

If you are building an application that's meant to be redistributed at all, you had better be using the long notation.

[Cups]

{show_tags}

would generate:

<?php if ( is_array($tags) { foreach($tags as $tag) { echo '<div class="tag">'.$tag.'</div>'; } } else { echo '<div class="notag">No tags

That certainly seems an interesting benefit, but isn't it pretty much the same as doing:

<?php show_tags(); ?>

in the straight "PHP as a templating language" solution?

You are in effect maintaining some kind of "view helper" in your code-base somewhere, else when you actually want to change that from displaying as a div to displaying in an UL, you have to amend some code squirreled away from your template code.

What if it is the designer who has to be able to affect that change?

I like the idea you mention about pre/post production though.

[Jake Arkinstall]

In my days of template research (about 2 months ago :P) I tried quite a few different techniques to template with.

Smarty... Well its a bit like PHP, so why not just use PHP instead and get rid of the overhead?

Tag replacement (i.e. ~varName~, #FuncName#) - Handy but PHP could do this with just '<?php echo $Content->varName; ?>' - yeah its longer but you can do more with it.

XML Parsing. Yes, I even went down the route of adding innerText to elements with a certain attribute using the Dom, a bit like how .Net does it. This was the most useful and fun to implement, but it was alot heavier on the system and added over 50&#37; to the output time.

In the end I decided to go back to PHP-based templating. PHP itself is a fully fledged programming language (obviously) so offers much more flexibility than other methods. It is also native to the compiler so adds no extra effort to parse. I knew it, so I don't need to have to think about how to do something, and it requires no extra programming on the back-end. Its not hard to write functions with PHP, so why people think that templating systems with functions is a benefit, when write the same functions themselves, I don't know.

Of course problems arrise when the designer wants to change something, but there are solutions around this.

Realistic methods include a dual templating system. The designer specifies their own preference of inputting dynamic code into the file, be it XML or templating - whatever they like. From that a parser could be easily made which generates a PHP file from it, and this means that extra processing need only occur once, and it needn't be on the actual server.

However, my all-time favorite is a little sunken drawing pin on the designer's seat that quickly fires when any PHP code is touched, but of course this adds overhead to the designers computer and chair .

[ramupl]

Well, I agree that functions aka view helpers would be the better way of including proper php into templates without going the route of template parsing. something like what Wordpress is doing. Though its a pain to anticipate and create functions for everything you want to do in a template

[imaginethis]

Why?

I thought Template Engines were a waste of time, what would be the advantage of writing it in C if there is no need for them in the first place?

No, writing a template engine in a template engine is a waste of resources. Writing a template engine in C isn't the same thing as writing it in PHP. Writing it C it would be much faster, less portable, but faster.

[F.Danials]

No, writing a template engine in a template engine is a waste of resources. Writing a template engine in C isn't the same thing as writing it in PHP. Writing it C it would be much faster, less portable, but faster.

So PHP is more portable, although a waste of resources?

[Cups]

Well, I agree that functions aka view helpers would be the better way of including proper php into templates without going the route of template parsing. something like what Wordpress is doing. Though its a pain to anticipate and create functions for everything you want to do in a template

Well thats about it really isn't it?

If I understand it, in many team situations html templates are there primarily to provide a means of delegating to non-phpers (or evil users, if you are paranoid/realistic) the ability to change what is displayed on the site.

Note : not just how things are displayed, but actually which data are displayed.

Using a template language, to a large degree I guess, limits the damage that these users can do by offering a subset of abstracted PHP functions, simple loops etc.

Is it true that templates are used mostly as a read-only display mechanism?

For a long time I mistakenly believed that templates were the V in multi-layer frameworks like MVC, but in effect they often rely on objects such as view-helpers to negotiate and retrieve the data they need.

Perhaps read-only-view-helpers written in C would be a good idea?

Take simple table data retrieval.

Maybe addressing pagination, handling null results variable length arguments, optional non-phper notices etc.

In non-production mode, all the non-phper generally wants to stipulate is which table, which fields, which order.

Just gimme the data for my loop.

All the programmer really wants to stipulate is which tables are disallowed to be read, or which individual fields are disallowed to be read, and which table can be joined to what.

Heres your data. Tough, that field is out of your range.

...and something polite in the middle which says, "computer says no", "that field does not exist" or "1600 results? Here's 100, chew that over."

template <-> view-helper <-> Model (or Controller)

where view-helper consists of :

<-designer-negotiator-> <-programmer-negotiator->

where designer-negotiator tells them
what tables are available
what fields are available
what joined tables have been set up for them
error messages
data

and programmer-negotiator refers back
what cockups have been made
which non-existant fields are being asked for
but is told:
which tables are available
which fields are not available

These smarter view-helpers could then be clever enough to white list the necessary PHP functions that users can get their heads round like date format and money format, and leave those decisions to the designers.

[SpacePhoenix]

I fail to see the point in using template engines like smarty, i see their use as a waste of resources (overhead). I prefer to echo (view in MVC) the stuff and format it using css.

[F.Danials]

I fail to see the point in using template engines like smarty, i see their use as a waste of resources (overhead). I prefer to echo (view in MVC) the stuff and format it using css.

Using your method, how would you create a simple registration page?

[SpacePhoenix]

All a template needs to be is a normal html page but saved as a .php with values such as the page title ( in the <title><?php echo $page_title_here ?></title> ). The main page content would be dealt with by a view class (communicating with the model and controller classes). All formatting information should be dealt with by css and all positioning done using divisions and css.

[Michael Morris]

That's a matter of opinion. I find <?php foreach ($users as $user) { ?><a href="/<?php echo htmlspecialchars($user) ?>"><?php echo htmlspecialchars($user) ?></a><?php endforeach; ?> exceptionally hard on the eyes and a real pain to write. After I've mocked up a design in Photoshop and I want to write its corresponding HTML code, I don't want to waddle in such ugly code spaghetti. You also can't cleanly add template-specific functions to be used in only templates due to PHP's handling of scope.

You might want to look into how Smarty does it.

Then learn braceless syntax. <?php foreach( $array as $value): ?> some html here <?php endforeach; ?>