Template Discussion

From: Date: Tue, 21 Mar 2000 18:14:48 +0000
Subject: Template Discussion
Groups: php.template 
Request: Send a blank email to php-template+get-397@lists.php.net to get a copy of this message
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

« previous php.template (#397) next »