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

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.

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

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

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

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

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.

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?

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.

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

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

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

Thanks for acknowledging that, at least.

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

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.

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

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.

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

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.

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

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.

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

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.

Regards,

-Andrei
* Programming is an art form that fights back. *