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

Attachment: [text/x-vcard] Card for Dan Libby danda.vcf