RE: [Phplib-users] template extensions

[Layne W. <la...@of...>]

Before I reply to any particular statements, it appears to me that some
people on this list might be dealing with some internal project issues.
There have been several comments about not trusting the programmers and not
knowing what the final outcome of the project is going to be. You cannot
expect to solve your development problems, whether from communication or
incompetence in your team, by a clever software hack. If you cannot
coordinate programmers and graphic designers it is time to evaluate your
culture/environment and personnel.

On the other hand, I could be reading my previous experiences into your
emails. If so, please ignore the previous sentences.


Quoth Evan Hughes:
>   I'll be the first to admit that this isn't a huge saving. 
> All it gives us is:
>   a) Faster runtime (there's no risk of unused variables 
> being created)


This simply is not true. The current template implementation has the
following basic steps:

1. set variables in an array
2. preg_replace the variable names with the variable content
3. if unknowns is not set to "keep", replace all variable matches with empty
string or comment

The proposed change would add the following steps:

3. find each remaining variable (or function or whatever) match
4. loop through the result set
   a. find associated function, if it exists
   b. run function and replace in template with output

The problem is that the current implementation doesn't have to look at each
undefined variable - your implementation would.


>   b) Enforced encapsulation of variable definition into 
> separate files. Notice that this really encourages reuse.


What you should really consider doing here is separating the parts of the
page (header, footer, navigation, auxiliary content modules {e.g. calendar,
poll}, etc.) into their own templates. Write a function and/or class for
generating each piece and a function/class for building a dynamic layout
(this would then call the individual piece display code).


>   c) Greater decoupling of templates and their defining code.
> 
>   But it comes at virtually no cost. The only change to the 
> API that I see
> would be a "set_backing_dir(path)" which would set the path 
> to the directory
> that contains the files that would back the variables. 


API change does not equate performance cost.


>   As a side note: Consider the implications of (b) and (c) 
> from above. If we
> take the whole variable backing thing to an extreme, we can 
> move all of the
> dynamically generated content out of php scripts and stick 
> them into files. 
> This means we don't need any php between the templates and 
> the outside world. 
> If we use .htaccess to prevent download of .tpl files, and 
> catch requests for 
> them with an error_document handler (which would evaluate the 
> named template), 
> we can essentially provide an interface where we're just 
> serving raw templates.


Stop! What problem are you trying to solve here? Now you're talking about
content caching, which is completely different from variable layouts.

Also, you've mentioned in a couple messages that you would like to remove
PHP from the public site. If that is your true gain, you cannot rely on the
Template class - it's PHP!


> > Instead of putting those functions in the template, 
> couldn't you just put 
> > template variables in the template and have the PHP code 
> filling in the 
> > template perform the functions for those variables?
> 
>   You could. What Mike and I are suggesting is essentially 
> just a lazy linker: 
> instead of exhaustively defining all possible variables 
> before the script 
> is run (or worse, sculpting code that will conform to the templates), 
> simply move the resolution of variables to a just-in-time 
> model where they're 
> defined as needed. 


Hmmm. You don't want to have the code and the templates work together. Why
not? Do yourself a favor and put a bit of planning and thought into your
project before you build it.


> > Or, if there is some reason I am missing to want to do 
> this, why use 
> > templates at all?  Why not just use straight PHP and use 
> <?php include 
> > your_function.php; ?> or <?php your_function(n); ?> in 
> place of your 
> > curly-bracketed functions?
> 
>   Because that mixes presentation with logic. As soon as it's 
> in vanilla php,
> we lose the ability to use templates (unless we're calling 
> out to other files,
> etc). 


I have found it useful to combine the techniques - I have built sites that
use includes to build portions of dynamic content with the Template class.


Layne Weathers
Ifworld Inc.