Re: [PHP Template] Re: [PHP3] PHP Template Engine spec revision 0.52

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> 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.

Powerful doesn't necessarily mean it's good, if it's just yet another way
to do the same thing as another powerful tool.

> > 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.

Two completely different ways to implement the same thing is a strength?
In what sense?  Every PHP developer would now have to know two languages
that have nothing to do with each other, if he wants to be sure that he'll
be able to understand PHP scripts?  It's a bad thing in every aspect.  If
it was powerful in a sense that it was *adding* functionality, not
duplicating functionality, it would be a good thing.  Providing a totally
different way of doing the same thing, in the language-syntax level, is
bad.

> Firstly, if you can make predictions for the future, then you should be
> playing on the stock market. :)

In the opensource world, if you release something, someone, somewhere,
would use it.  And from my experience, lots of people use just about
everything.  So, my prediction about this, and I don't have to be a
prophet for that, is that there'll be lots of people that would use the
template syntax, and obviously lots of people that would go on using the
PHP syntax.  A predicion saying that no-one would use the template engine,
or alternately, that everyone would use it, is a predicion you would need
a prophet for.  Saying that both will be used is just common sense.

> 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.


Either you didn't understand me, or that's a very big 'if'.  Your template
syntax lets people take foo.php, which is full of logic, and convert it
almost as a whole to foo.tmpl, with (almost) all of the logic inside the
template.  This means that you would have two files, foo.php and foo.tmpl,
that look completely different, are essentially written in two completely
different languages, but do the same thing.  You can't say that foo.tmpl
would be easier to develop/maintain, because that's just a matter of
opinion (whether someone thinks that {if} {/if} is more intuitive than
if() { } is very subjective).

You're introducing a whole new language, with LOTS of power that overlaps
the existing PHP power, only with completely different syntax.  That's
bad.

> 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.

Please, people do not want to learn new things if they don't have to,
especially if it gives them nothing!  The template logic is NOT easier
than PHP logic, it's just different.  Enforcing people to study yet
another language is pure overhead, and has no reason at all.  Again, this
is in contrast to standard, plain&simple templates, which have a flat
learning curve, and require no programming skills to master.
 
> 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 would have to see the final 'product', but if it grows up to match that
spec (which would probably get even more complex as time goes by), I for
one, would oppose adding it as a standard to PHP.  If I'm the only one
that thinks it's a bad idea, than I guess you can ignore me, but I think
that there would be many others that think that as well.  Just because the
designers in your company don't like PHP's syntax and prefer a totally
different syntax to do the same thing, doesn't mean PHP should have a
whole new syntax introduced, something that would cause lots of pain for
lots of people in the future.  I'd be all in favour of implementing a fast
plain&simple template engine at the PHP level, after receiving positive
feedback about the need for templates (without logic) from many people,
both in Zend and in ApacheCon.  If you recall, the 'should we have
built-in template support in PHP' argument at the PDM ended the second you
said there should be if constructs in there - everyone said 'no way', but
I don't firmly object the concept of templates, despite the fact I
wouldn't use them myself.

> > 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.

At the PDM we decided not to add templates at all, and you decided to
pursuit this project yourself, which you have every right to, obviously.
But I think the spec got completely carried away, and poses a significant
problem to the uniformity of PHP as a simple and easy to use language.  At
any rate I wouldn't want the template engine to be at the language-parser
level, but I wouldn't want to introduce a whole new syntax in whatever
level.  Much like I wouldn't want to add a Visual Basic parser on top of
the PHP parser to let people mix VB with PHP, I don't want the template
engine to be powerful enough to replace PHP logic.  If it can do it, it
means it's too powerful.


> > 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?

Nothing, but that's a trivial template, that you can do with the other
template engines available (which is fine by me).  In your spec, you have
loops, if constructs, and whatnot.  This is wrong, since it can be done
using equivalent PHP logic.

> 
> > 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.

It needs to be mixed with PHP logic.  The only reason for not doing this
is that your designers seem to prefer another logic syntax over PHP's
logic syntax, which in my opinion, is not a valid reason.  If they were
used to VB, or JSP templates, you would write new VB/JSP parsers that
would let them mix code from different languages?  That's horrible IMHO,
because it would mean that every PHP programmer would have to know these
languages before he can understand PHP scripts he finds on the net (sooner
or later, people would begin using it, and scripts that use it will be
published on the net).  The template spec is just another language, just
like VB/JSP (except it's a whole new language on its own, and not a
duplicate of an existing language).


> > 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 think that in this case, it's a great example of why you shouldn't
implement all this logic in the template level.  You would also have
{ if #baskettotal > 10 }
and
{ if %baskettotal > 10 }
and God knows what else, each would mean something different, and a
possible reader would have to be familiar with the details of this spec in
order to understand it.  True, the PHP version is slightly longer since it
requires you to explicitly say you're referencing a template variable (the
rest of the different is just syntax), but the fact that people will not
have to learn a whole new language is definitely worth it.

> 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.

Well, today was the first time I actually read through the spec, and I was
quite surprised to see a full-featured language laid out in there, instead
of something that implements something similar to the template engines
I've seen before.  If logic, written in PHP can be rewritten in your
template syntax, with completely different syntax, I think the spec lost
it's path somewhere along the way.

Zeev

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