Re: [PHP Template] Re: [PHP3] PHP Template Engine spec revision 0.52
[email protected] (Andrei Zmievski) Tue, 21 Mar 2000 09:43:46 -0600
| Newsgroups | php.template |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 21 Mar 2000, Zeev Suraski wrote:
> I'll try to say why I think it's actually very bad for PHP to have a
> powerful template engine, and why it's not harmless.
Ghm.
> The way I see it, if the templates engine actually gets implemented
> successfully, then people would see it as an integral part of the
> language. Now, some would think it's better to use, and some won't. The
> thing is, you would now have two very very different ways to implement
> your logic.
I and many others view it as a strength, not a weakness.
> Writing a certain script would be possible to do in two *completely*
> different languages, but both are considered PHP. The two versions of the
> script will have NOTHING to do with each other, and a person understanding
> one version of the script (say, the PHP-code version) will not understand
> the other (template) version. Suddenly, someone who knows PHP will no
> longer be able to understand a large (or rather, unknown) portion of the
> PHP code that will be out there. A book that doesn't cover templates will
> no longer be enough, since without being aware of the complex template
> syntax, which is essentially a language in its own right, you won't be
> able to understand many of the scripts out there. That is why I think
> that every single person on this mailing list, or at least most of them,
> would be affected by such a template implementation, and thus, I think the
> discussion belongs here rather than a cut-down 'for template
> professionals' mailing list.
Firstly, if you can make predictions for the future, then you should be
playing on the stock market. :) Secondly, I disagree with your opinion
that the same application written in PHP and in PHP+templates will have
_nothing_ to do with each other. If the application is written properly,
then they will have a lot in common. Thirdly, you seem to be afraid that
people who already know PHP will be loathe to learn something new that
will empower them. Do not underestimate people's desire for learning.
I have to stress once again that, perhaps, a wide range of developers
will not even have a need for a template engine. They can happily go on
developing the way they've been doing it now. But then there are those
of us who have work day in and day out with the designers. We tried
writing applications with HTML embedded PHP code. Our designers
screamed and said they'll never touch something like that again. PHP,
while a greatly generalized language, is not a good choice for
templates because of its C/Java/Perl legacy and other issues. That's why
we want a template language and, yes, it has its own syntax and rules.
> I think that in the way the spec is laid out right now, templates are
> truly a language inside a language, and regardless of their specific
> syntax, it's always bad to have two completely different syntaxes to do
> the same thing, *especially* if you're staying in the scope of the same
> language (I think we would be one of the first examples for this, and it's
> not a very good thing!).
Yes, they are a language inside a language. But if you remember from the
Developers' meeting, we did not want to touch PHP's parser in order to
accomodate some features of the template engine (like sections, for
example). That's why I decided to write an implementation using its own
syntax that's more geared for layout stuff.
> As opposed to this, a trivial (in the literal sense) template
> implementation, which would literally have no learning curve, much like
> the template engine of phplib or the other ones available, does not impose
> that danger. It's really just a different way to lay out presentation,
> and it requires no learning of a new syntax, plus it doesn't give you the
> ability to write your logic using a completely different syntax.
Here is an example for this template engine:
template
--------
<HTML>
<HEAD>
<TITLE>{$title}</TITLE>
</HEAD>
<BODY bgcolor="{$bgcolor}">
...
</BODY>
</HTML>
PHP script
----------
$id = tmpl_load("template.tpl");
tmpl_assign($id, array("title" => "My Page", "bgcolor" => "#458830"));
print tmpl_fetch($id);
That is as simple as it gets. This is exactly what FastTemplate and
phplib's template system do. What's wrong with this?
> Is it powerful enough? I would say it is, knowing the underlying engine
> between some very big and complex web sites, the zend.com web site
> included.
That may be. For our company, it wasn't powerful enough. I suppose
others may agree with me.
> If your designers love the ability to write conditionals in their
> templates, which essentially means they're coding, they should truly learn
> the PHP syntax. Introducing a whole new syntax inside PHP just because
> your designers don't like PHP's syntax is a bad thing, regardless of
> whether that syntax goes directly to the scripting engine (which as you
> said, we don't want to change) or to a slightly higher level position.
It's not a matter of just learning PHP syntax. It means that we would
have to pollute PHP's namespace with template variables and all that if
we want to do something like:
<? if ($TPLVARS["baskettotal"] > 10): ?>
as oppposed to
{ if $baskettotal > 10 }
That's just one example.
I'm glad people are coming out of the woods now and letting their
opinions be known. I wish they did it sooner. Perhaps, some of the
language syntax is getting to be not so obvious, but it's tough to
balance ease-of-use and flexibility for both designers and programmers.
I'm trying to do the best that I can under the circumstances and,
hopefully, we can all settle on an agreeable solution.
-Andrei
"Claiming Java is easier than C++ is like
saying that K2 is shorter than Everest."
-- Larry O'Brien (editor, Software Development)