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:
> > 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.
> 
> I think it's you who totally misunderstands what I was talking about. I
> am not saying that foo.php gets converted into foo.tmpl with all the
> logic inside the template. That's insane! Never once did I mention
> something like that! The template logic is meant to be used only for
> some of the layout stuff, nothing more. I don't know where you came up
> with foo.php -> foo.tmpl idea.

No, I understand that's not your intent.  But your engine *allows* that.
And if there's one thing I learned in the last 3 years, is that if it's
possible - people will do it.  It should not be possible.

> Exactly, the template logic is different! It has a different purpose.

It's not really different, it's just a different way to write it.

> Oh, and "a flat curve"? That's an oxymoron.

It makes a point.  You have no learning curve for the simple templates,
you know them inside out in anywhere between 0 to 5 minutes, depending on
how much programming experience you have.

> Why do you twist my words? No one is introducing a whole new syntax to
> PHP. Even if I wanted to do that, I still wouldn't be able to due to
> your de facto ownership of the Zend code.

It has nothing to do with ownership of the Zend code;  You are introducing
a whole new syntax.  De-facto, a .php script, could be converted to a
couple of lines of .php and an equivalent .tmpl file, that would look
completely different.  Of course it's not intermixed with the PHP syntax
in the low level, but essentially, it is.


> I also object to your argument that PHP programmers wouldn't understand
> PHP scripts that use templates. I'm sorry but that's a little
> ridiculous. You can apply the same argument to PHP scripts that use XML
> or classes or regular expressions. What if someone doesn't know OOP or
> regular expressions? Maybe we should make life easy for them as well,
> eh?

None of your example is similar to the template issue, except for,
perhaps, the OOP.  XML/regular expression don't replace PHP's syntax.  At
best, they give you different ways of doing the same thing, but they're
all under the same umbrella.  Your template engine gives a complete, or
perhaps not complete but way-too-comprehensive alternative to PHP's own
syntax, within PHP.
About whether or not we should have added OO support to PHP?  I don't
know.  Many people liked it, but undoubtfully, it did cause problems to
people that did not.  It's not a very good example in the sense that I
would have definitely not introduced something similar to a whole new
programming paradigm into PHP today, and the template engine is exactly
that.

> You seem that think that there should be one or two rigid
> ways of writing PHP scripts. One of the big advantages of Open Source
> movement is that it gives you _choice_. What a nice word.

That's marketing.  You can choose between languages, between products.
It's bad when you can choose between two completely different approaches
within the same language.  It only means the product/program is
inconsistent.

> 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.
> 
> Funny I received lots of positive feedback on the current spec as well.

It's not funny, and I'm not surprised that you did.  It's powerful, and
people who like templates will probably like it.  It doesn't change a
thing from what I said, though.  It's bad to have a template engine that's
powerful enough to replace PHP logic.  Not everything people like is a
good idea to add to the language;  I'm sure I could find dozens of people
that would appreciate adding VB constructs to PHP.  It doesn't mean it's
good or responsible.

> > 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.
> 
> So, if you don't use PHP yourself to build things, how can you say that
> PHP syntax is more applicable for the templates than the template
> language syntax?

Because there are 1.78 million domains on the net using it, with, at best,
a plain&simple template engine.

> > 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.
> 
> Whoah, hold on. There it goes again. Who ever said that template engine
> is going to replace PHP logic? It is not a programming language. It's a
> layout language. Closer to CSS if anything.

It can replace PHP logic, therefore, for some unknown amount of people, it
will.  If it's just 10 people around the world by year 2005 - no problem.
In my experience, it'll be lots of people and much sooner, even though you
didn't intend for that to happen.  
 
> I still don't understand why you feel that PHP is threatened by this
> template engine. Its use is optional. Just because we have XML extension
> or PCRE extension doesn't mean that you are obligated to use it.


The difference is that it gives you the ability to write the same code in
a completely different syntax.  XML doesn't do that, neither does PCRE.
They give you some sort of functionality, which you can decide you want to
use, or not.  They don't 'compete' with PHP.  Essentially, your template
engine is.  Your immediate reaction would be to deny that, but think about
it - your reasoning for using the template engine are because you think
it's better for some things ('no contest').  Who will draw the line on
what it's better for and what it's not?  I, and many others, don't agree
with you that it's even better for the examples you gave earlier.  Others
in the future, will probably not agree with you that it's NOT good for
smoe other things, and would end up writing lots of logic in that template
language instead of in PHP.  That's competition, and having two syntaxes
competing with each other within the same language is a Bad Thing.

> It may be a trivial template, but that's exactly what you propose
> having as PHP's template system. Obviously, the template engine can do
> this, but also other things, if you choose to take advantage of that.

I think I made my point on why giving the choice of using a whole
different syntax isn't a good thing.  Choice is indeed a good thing, but
between different programs, different languages, different operating
systems.  Not two syntaxes for doing the same thing within the same
language.

> How many times do I have to say it? It's not a programming language.
> It's nothing like VB/JSP. Enough of this FUD.

It is.  It has control structures - conditionals and loops, it has
expressions.  It's a programming language for any practical purpose, and
the fact you can compare template code snippets to PHP code snippets,
which you did, proves that.

> Ok. Then let's stop adding new extensions to PHP completely, because a
> possible reader would have to be familiar with Perl-style regular
> expressions, or sockets, or, God forbid, SQL syntax. The horror.

Functions are one thing, a whole new language syntax is another.  I really
think you're lacking some vision here, in realizing that as soon as this
template engine is available, people would use it for all sorts of things
you did not intend them to use it for, and it would bring small to medium
chaos.

> > 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.
> 
> The template logic is not meant to replace PHP logic. See above.

But it *CAN*.  That's the problem.

> If everyone subscribed to your philosophy, Zeev, we'd still be using awk
> and sed as our scripting languages instead of PHP, Perl, and Python.
> Three whole new languages. What an idea.

I actually don't think this is worthy of a reply, and you're in no
position to throw mud at me like that.  Anyway, I think what you're
missing over and over again is that this is not a new language, but
rather, a new syntax to an existing language, that duplicates large
portions of its functionality.

Zeev

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