What't the point of a template engine in a framework

**paalgg** · May 6, 2009, 00:07

I have been developing some functionality to PHP applications, but I haven't myself been making design or too much logic in the applications. Just algorithms and data structures, so I haven't been needing to understand how the application works.

Now I have looked into frameworks and application structure, and I start wondering what the point of template engines are when working with a framework? For example, I am looking into Yii and Zend framework and the use of Smarty templates. Most of the HTML output is generated by PHP code, and in the end all this HTML is inserted into an almost empty HTML file.

Many of my templates are just empty shells where I insert a Zend Form. I don't see the need for templates. Is there something I have missed, can someone put me in the right direction?

**danman** · May 6, 2009, 04:00

Reading about the reasons why to use Smarty templates on their own website, they talk some about that designers and programmers can work separated. The designers work on the templates and the programmars on application code.
So if that is a problem then it maybe could be a good approach to use something like Smarty..

"One of Smartys primary design goals is to facilitate the separation of application code from presentation. "

I try to separate application logic from presentation logic
having php loops in a the presentation layer for example has never caused a problem for me..

**Stormrider** · May 6, 2009, 04:17

Personally I think Smarty is horribly over complicated, and you don't really need a templating engine with a framework, as php is its own templating engine. However, there are some engines I quite like (xtpl being one), that really do separate presentation and logic (smarty still has if, foreach loops) and make maintenance easier as well. I've written my own templating engine based on the xtpl syntax. It uses blocks instead of loops - a block of code can be repeated 0 or more times - so that's conditions and loops taken care of without having to put those in the template.

**paalgg** · May 6, 2009, 04:21

This is just a template example out of many similar from a project I am working on:

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>Here goes the title</title>
  </head>
  <body>
  <h1>Activation</h1>
  {$form}
  </body>
</html>

The designer can never work with these templates unless i "hardcode" the forms into the templates.

I use Zend forms. Isn't the purpose of a template in this example gone?

**Stormrider** · May 6, 2009, 04:23

That's more to do with the use of the templates rather than the templates themselves. If all that HTML is just stored in a variable, no template engine is going to do anything differently. You should try templating the form itself maybe.

**FrlB** · May 6, 2009, 04:58

Originally Posted by Stormrider

Personally I think Smarty is horribly over complicated [...]

I'm just curious: What exactly do you consider is complicated in Smarty?

**paalgg** · May 6, 2009, 05:59

Originally Posted by Stormrider

If all that HTML is just stored in a variable, no template engine is going to do anything differently. You should try templating the form itself maybe.

The designers has nothing to work with in this example, so as you say, it is better to template the form too, but then i loose the functionality of the Zend form to validate and filter for example.

What you guys out there doing?

**World Wide Weird** · May 6, 2009, 07:09

The best reason to use Smarty is to keep designers out of your code. If you're the sole developer on a project (both front end and back end) there's no real reason not to just use PHP inline syntax.

**Stormrider** · May 6, 2009, 07:28

The trouble is, Smarty easily has the potential to break your code anyway. It has conditions, loops, array parsing, all sorts - easily enough for a designer to screw around with and mess things up. This is why I think smarty is over complicated as well. A look at the size of the documentation on the smarty site should tell you that is has too much power for a template engine (and therefore too much bloat).

**World Wide Weird** · May 6, 2009, 07:44

I've about decided that server-side template systems are passe in this age of AJAX and JST anyway. Let the client handle rendering the view. That's what browsers are made for.

**Stormrider** · May 6, 2009, 07:45

Well yes, but you need to pass them the HTML in order to do that... which is where the templating comes into play!

**World Wide Weird** · May 6, 2009, 07:51

It's impossible for a client-side JavaScript template system to break your PHP code unless you specifically give it that ability via AJAX calls or some other means.

**Stormrider** · May 6, 2009, 08:14

Yes, but then on the downside, it's a client side JavaScript templating system :P

**World Wide Weird** · May 6, 2009, 08:30

Originally Posted by Stormrider

Yes, but then on the downside, it's a client side JavaScript templating system :P

True. As in many things Web-related, user cooperation is required to make it work. So the real problem remains whether the user is so willfully defiant as to cut off his nose to spite his face.

**plaatspunt** · May 6, 2009, 09:32

Originally Posted by Stormrider

The trouble is, Smarty easily has the potential to break your code anyway. It has conditions, loops, array parsing, all sorts - easily enough for a designer to screw around with and mess things up. This is why I think smarty is over complicated as well. A look at the size of the documentation on the smarty site should tell you that is has too much power for a template engine (and therefore too much bloat).

Well it is even worse. Although smarty is a huge pile of php wrappers, it is still seriously limited compared to normal php. It has too little power.
I bang my head for having used this before in my projects. Of all templating approaches smarty is the stupidest.

**Stormrider** · May 6, 2009, 10:13

Too LITTLE power? The template should have very little power, with all the logic in the php behind it - display logic should go in a View Helper of some sort, not the template itself.

**plaatspunt** · May 6, 2009, 10:20

With power i do mean expressiveness. It should be possible to perform a simple string reverse or split by means of little syntax. Php is perfect for that.
Not all display logic should go into yet another view helper. But I agree that when reading your template you should easily the what, and not be bothered by the what. Many lines of formatting procedures into a template are not so nice. I think for example that putting breadcrumbs, pagination etc into a view helper is almost always a good idea.

**Stormrider** · May 6, 2009, 10:30

The example you used - reversing a string - you think that belongs in a template? I think that should go in the view helper, pagination is something more fundamental than that even and should go lower down in the chain.

**plaatspunt** · May 6, 2009, 11:00

PHP Code:


see your name reversed: <?php echo strrev($name); ?>

vs

PHP Code:


see your name reversed: <?php echo $this->reverse($name); ?>

I clearly prefer the former.

**Stormrider** · May 6, 2009, 11:23

I wouldn't use either if I was using a templating system. More like

HTML Code:

see your name reversed: {REVERSED_NAME}

PHP Code:


$objTemplate->assign('REVERSED_NAME', strrev($name));

**plaatspunt** · May 6, 2009, 11:30

And where do you want to put

PHP Code:


$objTemplate->assign('REVERSED_NAME', strrev($name));

In the controller?

**Stormrider** · May 6, 2009, 11:53

The view helper, which is set up by the controller and passed the model probably. I'd keep my business logic in the controller, but display logic in the view helper class, which in turn uses the template engine.

**FrlB** · May 6, 2009, 11:57

Originally Posted by plaatspunt

And where do you want to put

PHP Code:


$objTemplate->assign('REVERSED_NAME', strrev($name));

In the controller?

Why? This is clearly the view's responsibility.

**plaatspunt** · May 7, 2009, 01:58

I agree with FrlB. The controller shouldn't know about whether a name needs to be displayed reverse or something.

"business logic in the controller".
That's bad imho. Business logic should be put in the Model. The Model is not just data, it is a model.

Originally Posted by http://blog.astrumfutura.com

src: http://blog.astrumfutura.com/archive...preciated.html

A while back when I was writing the proposal (Zend_View Enhanced) that would eventually be adopted into the Zend Framework to create an object oriented approach to generating complex Views, I started moaning about Controllers being used as the sole method of getting data from Models into Views. My own thoughts were that Views could skip the middleman and instead use View Helpers to read data from Models more directly. This would support an architecture where in many read-only page requests, your Controller Action would be...empty. Devoid of all code. Nada.

In my mind, the best Controller is a Controller which doesn't need to exist

.

I was immediately treated to a mass of resistance. Few people seemed to understand that an empty Controller, with all Model interaction extracted into simple reusable View Helpers, would reduce code duplication in Controllers (lots of code duplication!) and avoid the necessity of chaining Controller Actions. Instead there was lots of muted puzzled expressions. Most people simply assumed that MVC worked as follows: requests go to Controllers, Controllers get data from Model, Controller gives Model data to View, Controller renders View. In other words: Controller, Controller, Controller, Controller. At one point I remarked that the entire community was obsessed with Controllers

. It's still tough going just to get anyone to give Views data objects, let alone let them read directly from Models...

Note: Not to sound like a complete pratt - some people did get the idea

.

None of the objections really caught on that this was an old idea. Java coined the term View Helper years ago as a design pattern in J2EE showing how View Helpers could assist Views in accessing Models (only on a read only basis since any writing should go through a Controller!) without the intermediary Controller. In MVC, there is every indication that Views should know about the Models they are presenting. Not just whatever arrays we decide to spoon feed them from Controllers.

So go further! How many Views only need one Model? A lot of my Views use several Models, with highly repetitive Model calls. A View Helper is a single class - but adding these repetitive calls to Controllers, means you need to duplicate calls into multiple methods!

One crazy solution created to outwit the View Helper, is often to reimagine Controller Actions as reusable commands. Whenever a View needs several Models, you just call several Controllers in sequence. This concept is something I call Controller Chaining - its premise is to create supporting code to make reusing Controllers possible. You can translate that as: reusing every class needed to execute a single Controller Action. Remember - you can't use any Controller without initialising the entire framework

. Though there are (there always are!) some exceptions.

**Stormrider** · May 7, 2009, 02:21

It depends on what logic we are talking about. Logic that is to do with the data itself, then yes, but some things still go in the controller i think - email notifications when updating something for example. It's not part of the data, but its logic that needs to go somewhere.

The SitePoint Forums have moved.

User Tag List

Thread: What't the point of a template engine in a framework

Thread Tools

Display

What't the point of a template engine in a framework

Bookmarks

Bookmarks

Posting Permissions