Re: [PHP Template] Revised proposal

Right.  I imagined something similar.  However, to me this implies that it will be
the template itself that is specified in the URL, not the PHP file.  This means that
the template processor must register another mime type with the webserver to handle
template files.  It really changes the paradigm, and I didn't go forward with it.
What does everyone think?  What do other templating systems do about this, if
anything?

I suppose an alternative is that your top level PHP code will have a specific
template associated with it.  It will do the first tpl_load(), and after that the
templates may choose their own PHP files.  This means you would need to have at
least one .php for each top level template.  I find that pretty gross.

-dan

Andrei Zmievski wrote:

> On Fri, 18 Feb 2000, Dan Libby wrote:
> > One could argue that this belongs at the application level, above the
> > templating system.  In fact, I've done something kind of similar here as a
> > testcase.  Basically, I wrappered tmpl_include() with a cobrand_include() and
> > then it includes the correct template for a given cobrand based on hostname.
> >
> > Still, the ability to use multiple templates with the same piece of code is an
> > attractive feature and I believe we should think about how to generalize it if
> > possible.
>
> Yes. The vague outline I see in my head is something like this:
>
> - Have another tag called {{processor ..}} which specifies the php
>   script.
>
> - Inside that PHP script should be function called process_template() or
>   something similar.
>
> - The engine will load the template and then check to see if there are
>   any processor tags and store them in the list.
>
> - At tpl_fetch()/tpl_print() time the engine will go through each
>   processor and call process_template()
>
> - process_template() will do assign/show/hide/whatever
>
> -Andrei
> * Ethernet n.: something used to catch the etherbunny. *