Re: [PHP Template] Revised proposal

[email protected] (Andrei Zmievski)
Newsgroups php.template
Message-ID <[email protected]>
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.

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

> 3) The if statements all assume scalar values for variables.  I assume
> this would work in a looping construct -- it would simply operate on the
> index currently be processed.

Exactly.

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

Let's say config file has this:

## globals ##
default_font = "arial,helvetica"

## section ##
[header]
default_font = "courier"

The parent template would just load the global default_font definition
and use it. The included header template loads default_font from the
[header] section, and uses that, but only within its scope, default_font
is still "arial,helvetica" at the parent level. To do something like
this from within the PHP script would be awkward, since you would need
to know ahead of time what templates are included and somehow match the
config file sections to them. And even then, since both included and
parent templates use default_font, there would be name collisions.

> 5) I think that tpl_hide (clear) is a useful API.

An explicit hide? Sure.

> 6) There should probably be a tpl_addval() API for adding a new value to a
> non-scalar variable.  useful for looping when you need to rearrange an
> array, eg:
> 
> $people = array(array("dan", "libby"), array("andrei", zmievski))
> while(list($key, $val) = each($people)) {
>   tpl_addval("fnames", $val[0]);
>   tpl_addval("lnames", $val[1]);
> }

Hmm, could be useful I suppose.

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

-Andrei
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.