Re: [PHP Template] Template Discussion
[email protected] (Andrei Zmievski) Wed, 22 Mar 2000 12:11:41 -0600
| Newsgroups | php.template |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 21 Mar 2000, Rasmus Lerdorf wrote:
> 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,
I've seriously thought about doing something like this before I started
on this template engine. I think it's a great idea for expanding
template _beyond_ the core functionality, but I think there may be a few
problems with trying to replace the whole template syntax with it.
1. The engine using flex for scanning the template. You can't really
have arbitrary delimiters in your language when you use flex, unless I'm
really not aware of something.
2. I can't really see how you can achieve the functionality of
conditionals and sections using this mapping. It's just a little too
generic.
3. All the template logic would be done by the userland PHP. I don't
know how that would affect performance..
I think that, perhaps, there could be a set of core functionality
similar to what I already describe in the spec, and we could also use a
system similar to yours to extend this core functionality. For example,
designers may want to print current date on the page. We could define
'currentDate' tag that would take an argument that specifies format and
calls a PHP function to do this. This would make the templates more
flexible and customizable to user-specific needs. But I don't really
think that you could implement implicit section loops and conditionals
using this mapping.
I know that the specification I wrote is pretty dry and technical, and
that may be turning people off or giving them wrong ideas. A couple of
people here are working on some things to better explain the vision for
the template engine. Hopefully, it'll mollify some minds and answer some
of the objections put forth in this argument.
-Andrei
* Ethernet n.: something used to catch the etherbunny. *