Re: [PHP Template] Revised proposal

From: Date: Wed, 16 Feb 2000 23:13:01 +0000
Subject: Re: [PHP Template] Revised proposal
References: 1 2  Groups: php.template 
Request: Send a blank email to php-template+get-94@lists.php.net to get a copy of this message
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

« previous php.template (#94) next »