Template processing styles

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Template processing styles

Ralf Eggert
Hi,

from different discussions in this list regarding the best template
processing style I noticed some different ways how to do it. Please
excuse me for starting another thread, but I think this subject is so
much important that it deserves its own thread.

From the previous discussions I collected three different ways of
template processing styles:

a) Use PHP itself as the template engine
b) Use the extended HTML tag style (like PHPTAL)
c) Use a custom tag style (like Smarty and many others)

Regarding a)

This way will work for projects with template designers who know what
they are doing, when using PHP itself as the template engine. But I
learned, that people might use PHP in their templates for more than just
template processing.

Many moons ago I worked in a project which separated the template
designers from the PHP programming team. For template processing the
project members used PHP itself. At some day the template designers
started using PHP for more than just template processing. After a while
the "templates" were full of PHP code for loading and processing files,
connecting to servers, reading and writing (!) databases and all other
kind of stuff that really should not be there. When asked why they did
that, the most frequent answer was: "Because it is possible!".

Fair enough, the main problem was the bad project management which
allowed this kind of chaos during the project time. But ever since then
I am healed from using PHP itself as the template engine.

Regarding b)

With the PHPTal style I have no practical experience. But a quick glance
on the introduction of PHPTal [1] made me shiver.

For template designers I think it might look quite complicated.
Especially the tal:condition and tal:repeat parts. In the example for
printing out a date a SPAN tag is added, which needs to be added to use
the condition and replace syntax.

    <span tal:condition="value/hasDate" tal:replace="value/getDate">
      2005-01-28
    </span>

I personally do not like it at all while others might love it. ;-)

Regarding c)

Finally, the custom tag style is the way I always preferred. I started
with my own home-grown template solution back in the good old days in
the last millennium, tried out other solutions like
PEAR::HTML_Template_IT and ended up with Smarty a couple of years ago.

I really like the custom tag style way of doing it, although Smarty is
suffering from the notorious open-source disease called "featuritis". To
be honest I think it is slightly bloated. I only use a couple of
variable modifiers like "cat" or "date_format", the "{$smarty}" reserved
variable, build-in functions like "{foreach}", "{if}", "{include}" or
"{literal}" and the Smarty caching mechanisms.

My Conclusion

I know there are many other ways of doing the template processing, like
using XSLT for template processing for example. The Zend Framework
already supports the a) style, but I think the framework really should
support other ways for template processing.

Although there are thousands of template solutions out there already, I
would prefer a custom tag style c) template processor which is based on
Zend_View to minimize the overhead for template processing. Although it
is possible to integrate Smarty into the Zend Framework [2] and [3], I
would prefer a lightweight custom tag style template processor which
only offers the basic functionality for processing templates.

But there could also be other solutions like the PHPTal style or XSLT
for template processing. I think we can learn from Zend_Search_Lucene
which is a solution for searching but the naming of this component keeps
room for other searching solutions.

So for template processing we could have (the names are just ideas, no
serious proposals):

Zend_View        => basic view and template functionalities
Zend_View_CTS    => process templates with the custom tag style
Zend_View_EHTS   => process templates with the extended HTML tag style
Zend_View_XSLT   => process templates with XSLT

What do others think? What does the Zend Framwork team think? Do you
only want to offer one solution that fits for most programmers (which
should be Zend_View_CTS) or do you want to offer a small variety of
template solutions?

Thanks for reading so far and best regards,

Ralf


[1] http://phptal.motion-twin.com/introduction.html
[2] http://devzone.zend.com/node/view/id/120
[3} http://devzone.zend.com/node/view/id/156
Reply | Threaded
Open this post in threaded view
|

Re: Template processing styles

Martel
Ralf Eggert wrote:

> What do others think? What does the Zend Framwork team think? Do you
> only want to offer one solution that fits for most programmers (which
> should be Zend_View_CTS) or do you want to offer a small variety of
> template solutions?

I like the idea of giving a spectrum of choices for the programmer and I hope XSLT
View will see the light of day somewhere in the future. I also like the phptal
inspired style because it keeps the templates very clean.

Great insights, Ralph. It is an important thread but your text is pretty thorough so
I wouldn't expect many replies other than those patting on the back. You didn't leave
any place for comments, you know ;)

> Ralf

--
Martel Valgoerad aka Michal Minicki | [hidden email] | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Idleness is not doing nothing. Idleness is being free to do anything." --
Floyd Dell
Reply | Threaded
Open this post in threaded view
|

Re: Template processing styles

Lee Queen
I think we should stick with  Zend_View using php as the main template
solution.  Maybe add a few classes for XSLT or another solution, but
let's utilize php for what it's intended purpose was, templating.  The
core view components should be php only and once the Zend_View libray is
far enough along, then possibly look at adding other solutions.  I think
it is very important to do all you can with php first without using
third party solutions, or other languages (other than standard HTML,
Javascript).  Just my two cents.

Lee

Martel Valgoerad wrote:

> Ralf Eggert wrote:
>
>> What do others think? What does the Zend Framwork team think? Do you
>> only want to offer one solution that fits for most programmers (which
>> should be Zend_View_CTS) or do you want to offer a small variety of
>> template solutions?
>
> I like the idea of giving a spectrum of choices for the programmer and
> I hope XSLT View will see the light of day somewhere in the future. I
> also like the phptal inspired style because it keeps the templates
> very clean.
>
> Great insights, Ralph. It is an important thread but your text is
> pretty thorough so I wouldn't expect many replies other than those
> patting on the back. You didn't leave any place for comments, you know ;)
>
>> Ralf
>

--

Lee Queen
Application Programmer
NC Division of Water Resources
Tel: (919)715-5441
Web: http://www.ncwater.org

Reply | Threaded
Open this post in threaded view
|

Re: Template processing styles

Johannes Orth
In reply to this post by Ralf Eggert
Hi,

> a) Use PHP itself as the template engine
> b) Use the extended HTML tag style (like PHPTAL)
> c) Use a custom tag style (like Smarty and many others)

> Regarding b)
>
> With the PHPTal style I have no practical experience. But a quick glance
> on the introduction of PHPTal [1] made me shiver.
>
> For template designers I think it might look quite complicated.
> Especially the tal:condition and tal:repeat parts. In the example for
> printing out a date a SPAN tag is added, which needs to be added to use
> the condition and replace syntax.
>
>     <span tal:condition="value/hasDate" tal:replace="value/getDate">
>       2005-01-28
>     </span>

I think you do not highlight a special problem of PHPTAL, but of all template
engines. To use a template engine you need to learn another language. In my
opinion the PHPTAL style is not more difficult to learn compared to Smarty
and others.

> I personally do not like it at all while others might love it. ;-)
:)

> Regarding c)
>
> Finally, the custom tag style is the way I always preferred. I started
> with my own home-grown template solution back in the good old days in
> the last millennium, tried out other solutions like
> PEAR::HTML_Template_IT and ended up with Smarty a couple of years ago.
I think that the smarty style is most widely used. But it is not technical
superior to other approaches. So this is again a matter of taste.


> What do others think? What does the Zend Framwork team think? Do you
> only want to offer one solution that fits for most programmers (which
> should be Zend_View_CTS) or do you want to offer a small variety of
> template solutions?
I would hate it, if the framework supports only one template style. As said
before I do not like smarty (others do not like PHPTAL, etc....), I do not
want the framework to make the decision which template engine I can use.

As it is already a matter of minutes to integrate an existing template engines
in the framework, is it really necessary to develop a ZF template engine? I
think there are only three possible reasons:

a) an integration with the framework which is not possible with existing
template engines (perhaps connecting the db classes to a template engine)
b) something new, which is technical superior
c) license issues

Johannes Orth
Bonn, Germany
Blog: http://www.johannesorth.de/kathry/
Reply | Threaded
Open this post in threaded view
|

Re: Template processing styles

Paul M Jones
On May 19, 2006, at 10:45 AM, Johannes Orth wrote:

>> a) Use PHP itself as the template engine
>> b) Use the extended HTML tag style (like PHPTAL)
>> c) Use a custom tag style (like Smarty and many others)

Zend_View currently supports all of these.  To restate earlier  
points: Zend_View exists only as a way to separate view scripts from  
controller scripts, not as a template system per se.

For example:  your controller instantiates Zend_View, gives it  
variables, then tells it to use a particular view script to render  
output.  The contents of that view script can be anything at all, the  
same way the contents of a controller method can be anything at all.  
This way you get good separation of concerns, so the controller  
doesn't have to know anything about how the view is handling its work.

For example, a view script can use PHP directly for output,

        <?php var_dump(get_object_vars($this)); ?>

or it can instantiate Smarty and use that template system,

        <?php
        include_once 'Smarty.php';
        $config = array(...);
        $smarty = new Smarty($config);
        $smarty->assign(get_object_vars($this)),
        $smarty->display('vardump.tpl');
        ?>

or it can use some future vaporware template system:

        <?php
        include_once 'PerfectSystemForEveryone.php';
        $perfect = new Perfection($this);
        $perfect->DoWhatIMean_NotWhatISay();
        ?>

You can even use different template systems in different view scripts  
if you want, because the controller has no idea how the view is  
handling its work.  All the controller knows is that a view needs to  
be rendered.

As such, I see no strong need for a Zend-specific template system;  
all that's needed is a way to separate the view PHP script from the  
controller PHP script.





--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.   <http://solarphp.com>

Savant: The simple, elegant, and powerful solution for
templates in PHP.   <http://phpsavant.com>


Reply | Threaded
Open this post in threaded view
|

Re: Template processing styles

Jayson Minard (ZF)
In reply to this post by Ralf Eggert
Hello Ralf,

All three options (and others) have value and in terms of working with them,
over the long haul it will be nice to see integrations to existing template
engines and also proposals for what might be new and unique and better (if
that is possible with all of the options out there).

Right now, the focus is on Zend_View with the ability to integrate other
options.  Later, when we have a LOT of time, we'll look at other options
within the framework.  This is one of the more complicated areas to get
into.  

The right timing is probably when we get into looking at components models
and their needs since that changes the game a bit.

If there are places where we aren't template engine friendly right now, we
should look at those, otherwise let's keep this brewing in the background.

--j

 


On 5/19/06 1:07 AM, "Ralf Eggert" <[hidden email]> wrote:

> Hi,
>
> from different discussions in this list regarding the best template
> processing style I noticed some different ways how to do it. Please
> excuse me for starting another thread, but I think this subject is so
> much important that it deserves its own thread.
>
>> From the previous discussions I collected three different ways of
> template processing styles:
>
> a) Use PHP itself as the template engine
> b) Use the extended HTML tag style (like PHPTAL)
> c) Use a custom tag style (like Smarty and many others)
>
> Regarding a)
>
> This way will work for projects with template designers who know what
> they are doing, when using PHP itself as the template engine. But I
> learned, that people might use PHP in their templates for more than just
> template processing.
>
> Many moons ago I worked in a project which separated the template
> designers from the PHP programming team. For template processing the
> project members used PHP itself. At some day the template designers
> started using PHP for more than just template processing. After a while
> the "templates" were full of PHP code for loading and processing files,
> connecting to servers, reading and writing (!) databases and all other
> kind of stuff that really should not be there. When asked why they did
> that, the most frequent answer was: "Because it is possible!".
>
> Fair enough, the main problem was the bad project management which
> allowed this kind of chaos during the project time. But ever since then
> I am healed from using PHP itself as the template engine.
>
> Regarding b)
>
> With the PHPTal style I have no practical experience. But a quick glance
> on the introduction of PHPTal [1] made me shiver.
>
> For template designers I think it might look quite complicated.
> Especially the tal:condition and tal:repeat parts. In the example for
> printing out a date a SPAN tag is added, which needs to be added to use
> the condition and replace syntax.
>
>     <span tal:condition="value/hasDate" tal:replace="value/getDate">
>       2005-01-28
>     </span>
>
> I personally do not like it at all while others might love it. ;-)
>
> Regarding c)
>
> Finally, the custom tag style is the way I always preferred. I started
> with my own home-grown template solution back in the good old days in
> the last millennium, tried out other solutions like
> PEAR::HTML_Template_IT and ended up with Smarty a couple of years ago.
>
> I really like the custom tag style way of doing it, although Smarty is
> suffering from the notorious open-source disease called "featuritis". To
> be honest I think it is slightly bloated. I only use a couple of
> variable modifiers like "cat" or "date_format", the "{$smarty}" reserved
> variable, build-in functions like "{foreach}", "{if}", "{include}" or
> "{literal}" and the Smarty caching mechanisms.
>
> My Conclusion
>
> I know there are many other ways of doing the template processing, like
> using XSLT for template processing for example. The Zend Framework
> already supports the a) style, but I think the framework really should
> support other ways for template processing.
>
> Although there are thousands of template solutions out there already, I
> would prefer a custom tag style c) template processor which is based on
> Zend_View to minimize the overhead for template processing. Although it
> is possible to integrate Smarty into the Zend Framework [2] and [3], I
> would prefer a lightweight custom tag style template processor which
> only offers the basic functionality for processing templates.
>
> But there could also be other solutions like the PHPTal style or XSLT
> for template processing. I think we can learn from Zend_Search_Lucene
> which is a solution for searching but the naming of this component keeps
> room for other searching solutions.
>
> So for template processing we could have (the names are just ideas, no
> serious proposals):
>
> Zend_View        => basic view and template functionalities
> Zend_View_CTS    => process templates with the custom tag style
> Zend_View_EHTS   => process templates with the extended HTML tag style
> Zend_View_XSLT   => process templates with XSLT
>
> What do others think? What does the Zend Framwork team think? Do you
> only want to offer one solution that fits for most programmers (which
> should be Zend_View_CTS) or do you want to offer a small variety of
> template solutions?
>
> Thanks for reading so far and best regards,
>
> Ralf
>
>
> [1] http://phptal.motion-twin.com/introduction.html
> [2] http://devzone.zend.com/node/view/id/120
> [3} http://devzone.zend.com/node/view/id/156
>