Re: [PHP Template] Re: your mail

On Tue, 29 Feb 2000, matthew patton wrote:
> SQL deleted. And yes, I would have to take the query result set and
> construct the properly nested multi-dimentional array of values. But that
> is what scripting is for.

Why construct some pretty complicated nested multi-dimensional array,
when you can just iterate over the SQL results and call some nice
tmpl_*_assign() functions?

> Indeed, but allowing the designer to unilaterally introduce "$_quantity *
> $_price" means I the script writer don't have to figure out where in the
> array of values to stuff the computation. For all I care he (html
> monkey) can make a nonsense value by taking the subtotal of all items
> bought by the customer, and finding their standard diviation. and put that
> on the end of the table. My responsibilities to the designer are to give
> him the data building blocks in an understandable and logical manner. He
> is free to derive whatever screwball values he wants.

I guess we have a bit different view of the designer's role in this
whole process. You think that the designer should be able to take values
from SQL results and manipulate them to no end (using mathematical or
some other means). I think that the designer should not have to subject
herself to any sort of calculations and instead simply use the values
provided by the programmer. In our company, for example, we design the
application screens first, before any programming is done, so both the
designer and the programmer know which values go where.

> It doesn't. But it's seen the "section" keyword come by and it's now in
> "section" mode which means, variables (unless assignment is involved) are
> immidiately evaluated and their values substituted into the buffer. It's
> also keeping track of that "master array", where it's at in it, what
> variables are (un)set, and is housekeeping those special #FIRST
> etc. variables. Now, not having looked at the parser, this may not be very
> easy to do. I don't know.

Like was said before, rewriting PHP parser is not really an option, so
I'm doing a separate one.

> longer really a template. But, I just might want to be able to call a
> standard routine to upper/lowercase a string, run tallies, do some trivial
> math (the programmer is not going to appreciate having his datastructure
> evolve on him as the designer discovers he wants more values that are
> simply derived from the basic ones),

You're right about wanting to uppercase/lowercase a string and similar
functions, and I'm thinking about how to best provide for that.

> display it URL encoded or BASE64 it one place and not another,

This is going to be provided for in the proposed template engine.

> ... If I were the programmer I'd start shooting
> my designer in the foot or worse. It gets better. What if the
> "template" isn't really a single documetn but an assembly of several? Many
> folks have standard HTML headers, footers and the like. So it's not at all
> unreasonable for the 'template' to include(corporate_header), and then
> finish with an include(static_corporate_footer) or whatever. Now you're on
> the hook to implement {{ include(...) }} too. The feature creap will have
> no end.

If you read the specification, you'd notice that {{ include ... }} is
already in there. And it's not that hard to do. Using PHP's <? include
?> is not possible because of all the parsing that needs to be done.

> I guess we disagree there. I look at it as just being a special mode of
> 'normal' PHP.

I like having separate template engine, because it means that it's
loosely coupled to PHP and can possibly be rewritten for another tool
using the same template grammar.

> I guess I'll just have to come up with an implementation and see how it
> stacks up. I am certain you'll beat me to it.

Good luck.

-Andrei
* The future has arrived, it's just not evenly distributed. -W. Gibson *