Re: [PHP Template] Revised proposal

Andrei Zmievski wrote:

> On Wed, 16 Feb 2000, Dan Libby wrote:
> > 2) I think there are issues with include.  Suppose that:
> >
> > designer creates template a.
> > developer writes code to load and fill in vars for template a.
> > designer (or someone) later includes template b from template a.  template
> > b has variables not filled in by code.  This is broken.   I suppose the
> > same is true if designer goes back and adds a random new var to template
> > a, but it just seems problematic to me.
>
> So the designer shouldn't create any new variables that are not filled
> in by the code. If template A includes template B, then template B will
> be expanded into A at tpl_load() time so any variable that's assigned in
> A will be assigned in B as well.

Right.  I guess the problem I see is that when people do an include they expect
it to be self-contained.  So in the above example, template b may have been
written by someone else 3 months before, and the designer suddenly says, aha --
I could use that here.  So there has to be understanding by everone involved
that include has a different meaning here than in other systems and that such a
template would have  to be thoroughly checked to make sure it doesn't use any
unknown variables.

This may just be a process issue, or maybe it won't come up as often as I fear.

> > Another thing is the issue of how to specify the include files.  Is the
> > path relative or absolute? Should absolute paths be allowed? If relative,
> > is it relative to the current template or to the current request?  I would
> > tend to say that it should be relative to the parent template, or if
> > absolute, then that is relative to doc_root, not file system root.
>
> We could have it either relative to parent template or have
> tpl_set_root() to set the root template directory for the application.

I'd prefer defaulting to doc_root.  Then we could have tpl_set_root allow an
override for someone
that really wants to use something elsewhere in the filesystem (depending on php
settings).

> > 4) still not convinced of need for config vals.  Why couldn't PHP code
> > load any needed values and fill them into the regular vars?
>
> Let's say the designer sees a commonality between different templates
> and decides to split out the common portion and include it in each
> template via {{include: ..}}. She also makes a new section in config
> file which has value just for that new included template. With
> {{config:...}} she wouldn't need to bother the developer to load the new
> section and assign it to template - that's #1. Also, the config vals in
> the included template will automatically override the config vals in the
> parent template but only within its scope. Example:

Okay, sounds reasonable enough.  I'm all for flexibility.

> > 7) I think that tpl_getvars() is useful so you can determine if a
> > particular value has been set or not.
>
> tpl_getvars() should probably take an optional varname if you want to
> find out the contents of just a particular variable.

agreed.

-dan

begin:vcard 
n:Libby;Dan
tel;work:650-210-2356
x-mozilla-html:TRUE
url:http://www.epinions.com
org:Epinions.com;Engineering
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Morlock
note:We're hiring at epinions.com.  Engineers, site designers, QA -- we need you.
fn:Dan Libby
end:vcard