Re: [PHP3] Template Discussion

I'm glad you stepped into that discussion.

Look, I'm not arguing with Andrei on whether his designers want these 
features or not.  I believe him they want them.  On the other hand, I think 
that the number of people who think that logic of the sort you can find in 
his template spec does not belong in templates is far greater than the 
number of people who do, based on my experience with people in Zend, 
ApacheCon, and even on this list.  You don't have to know much about 
templates in order to realize the danger in having the ability to write the 
same script in two completely different syntaxes.

The question is whether because Andrei's designer friends, and some others' 
preference of CF-like syntax is a good reason for introducing such a 
powerful template engine, that only goes half the way in separating logic 
from presentation, and duplicates some of PHP's strong features in a 
limited manner.  In my opinion, the answer is 'no'.  I'm not claiming to 
have years of experience with template systems, but my common sense tells 
me it's wrong and unnecessary, and if a few dozens of other people who do 
have experience with templates for a long time tell me my understanding is 
correct, then I truly think this whole approach should be reconsidered.

The template spec may be designed to meet a specific project or a project 
paradigm in ISPI, and I guess it does, since Andrei said a couple of times 
he needs each and every feature for an upcoming project.  I can't argue 
with that.  I can argue on whether this should be PHP's 'official', 
standard approach towards templates.  I think it shouldn't be, and that we 
should have a much simpler, presentation-only templating system built into PHP.

Zeev

At 20:14 21-03-00 , Rasmus Lerdorf wrote:
>The template discussion predictably is/was quite heated.  My opinion on
>the whole issue is mixed.  I have a deep hatred for layers.  Years ago
>when PHP first came to be, it was actually intended to be a templating
>system with business logic being written in C and linked into the PHP
>binary.  However, since needing to recompile your web server in order to
>add new business logic was quite cumbersome, the templating tag system
>expanded to the point where it became a language in itself and instead of
>writing business logic in C, business logic migrated to the template
>tagging language.
>
>We do not want to repeat this situation which I think is what sums up Zeev
>and Andi's arguments and was also the main point brought up at the meeting
>in Israel a few months back.  On the other hand, there is clearly a need
>for templates.  Whether we agree with this need or not, people want them
>and they will go to great lengths to get them.  To the point where they
>are perfectly willing to do multiple passes of template files and perform
>full regular expression replacement operations.  Ouch!
>
>I think the focus of a new template system should be to make absolutely
>sure that in 3 years nobody is going to ask for a templating system for
>the templating system.  If somebody does, I will personally go and beat
>Andrei to a pulp.  Secondly, the templating system needs to be much
>quicker and better architected than what you get from doing a series of
>regular expression replacements.
>
>Now, how do we do this?  My own opinion is that it would be wonderful to
>have a general-purpose templating engine that you could feed some sort of
>template definition file to.  I don't believe we can convince the entire
>world to use the same template system.  However, if we could provide them
>with a tool that makes it easy for them to define a template system we
>would really have something.  It also means that nobody would ever be
>tempted to layer yet another templating system on top of an existing one
>because they could simply write a new template definition file or edit the
>current one to make it do what they want and thus we have effectively
>stopped this vicious templating cycle in its tracks.
>
>I started looking at this about 2 years ago but pretty much determined
>that I would need a version of yacc/bison in which I was allowed to change
>the grammar on the fly and unfortunately such a program does not exist as
>far as I know.  With the huge growth of PHP and the massive influx of
>younger and brighter programmers to the project perhaps this approach
>warrants a second look.
>
>As for the current template proposal.  I would personally prefer for it to
>be simpler as well, but I have much less experience dealing with designers
>and I trust that Andrei and others who claim that some of these more
>advanced features are needed know what they are talking about.  However, I
>would love to see this particular implementation being just one templating
>instance defined in some concise manner in a general purpose templating
>engine.
>
>Just to give some idea of the concept here.  Take this line of template
>code:
>
>    <html><#my special tag#></html>
>
>The template definition file behind it might look something like this:
>
>    tag-start: <#
>    tag-end: #>
>    entity start {
>       name: my
>       args: arg1 arg2
>       map_to_php_function: my(arg1,arg2)
>    }
>
>With only a couple of minor changes to the template definition file the
>exact same result could be had by doing something like:
>
>    <html>[my]</html>
>
>The template definition file behind it might look something like this:
>
>    tag-start: [
>    tag-end: ]
>    entity start {
>       name: my
>       map_to_php_function: my('sepcial','tag')
>    }
>
>The final HTML output would be the same for both of these.
>
>This is obviously a completely dumbed down example and it doesn't address
>any of the more advanced concepts in Andrei's proposal, but I am throwing
>it out there with the hope that somebody has some interesting insights.
>
>-Rasmus
>
>
>--
>PHP 3 Mailing List <http://www.php.net/>
>To unsubscribe, send an empty message to [email protected]
>To subscribe to the digest, e-mail: [email protected]
>To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
>To contact the list administrators, e-mail: [email protected]

--
Zeev Suraski   <[email protected]>  http://www.zend.com/