Template Discussion
[email protected] (Rasmus Lerdorf) Tue, 21 Mar 2000 10:14:48 -0800 (PST)
| Newsgroups | php.template |
|---|---|
| Message-ID | <Pine.LNX.4.21.0003210913510.793-100000@adsl-63-199-162-61.dsl.snfc21.pacbell.net> |
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