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

[email protected] (Zeev Suraski) Tue, 21 Mar 2000 07:30:23 +0200 (IST)
Newsgroups php.template
Message-ID <[email protected]>
On Mon, 20 Mar 2000, Andrei Zmievski wrote:

> At 12:38 AM 3/21/00 +0200, Zeev Suraski wrote:
> >I want to add that this time I wasn't just saying what my personal
> >thoughts were, but was representing the impression I got from quite a few
> >hardcore PHP developers, that developed applications with the layout being
> >written by others.  All of them replied 'no way?!' (or something along 
> >the lines of this) when I asked them whether templates should have logic
> >(control structures) inside them.
> 
> Well, you should really have asked them to join this list then instead of
> talking to them privately and then just passing on their opinions.

Again, most of them wouldn't be interested in joining a mailing list just
to say this.

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.

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.  Essentially, two different languages in the same package.

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.

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

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.

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.  

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.

I would really like to hear from people whether they think I'm just being
'paranoid' about introducing a complete new syntax set for PHP being a bad
thing.  If my thoughts are correct, then this discussion does belong here,
because as I said, in a year's time or so, it'll affect every single PHP
developer out there.

Zeev

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