Re: [PHP Template] Re: your mail

On Tue, 29 Feb 2000, matthew patton wrote:
> well, OK. that's what I was going to use inline comments for.
> The thing is, the printf() style construct is rather useful when you've
> got multiple variables per block. I'm not completely clear but I think
> yours does support this, yes?

Perhaps, you can explain what you mean, since I'm not entirely sure.

> Customer1
> 	item1_count item1_SKU (desc) item1_price subtotal
> 	item2_count ....
> 	item3_count ...
> 
> Customer2
> 	item1_count ....

Ok, we'll come back to this example later.

> Having looked at HTML::Template now, I see what you're trying to achieve.
> Thus my data structure would look like (note, these are all values):
> 
> instance = { customer1,
> 	     {
> 		{ item1,
> 		  { quantity1,
> 		    price1,
> 		    descr1
> 		  }
> 		},
> 		{ item2,
> 		  { quantity2,
> 		    price2,
> 		    descr2
> 		   }
> 		},
> 		...
> 	     }
> 	  }

Well, it seems to me that you would not get this kind of data structure
from a database. You would most likely do something like this (if you
want to get the listing of all items per customer along with their total
quantity and price):

   select customer, item, sum(quantity) as item_qty, price, descr
     from orders
 group by customer, item

Results being, for example:

"Joe", 5858, 2, 29.99, "red shirt"
"Joe", 1295, 3, 19.99, "blue shirt"
"Bob", 7333, 1, 24.99, "green shoes"

> We have yet to introduce any non-standard PHP constructs.

Per previous e-mail, we'd have to, because we cannot involve PHP parser
in this.

> Now here's another interesting twist. Notice that my
> "plcae_holder" variables ($_customer, $_item, $_quantity, $_price) are
> just that. Those names DO NOT EXIST in the passed multi-dimentional array
> which is strictly a bunch of values. (this relieves the
> programmer and the template engine from having to deal with
> that particular mess) Furthermore, their visibility is restricted to
> within enclosed "section" blocks. In other words, if you have a variable
> in the main PHP file with the same name, it's value will be substituted
> instead of being assigned the apropriate value from the parameter
> array. (this may not be a desireable feature as it requires 'safe'
> variable naming practices but it's the only way I can think of.) But on
> the other hand a variable first seen within a section block will not be
> visible to the rest of the PHP file or to outer "section" blocks. ie. it
> will get unset as soon as execution pops out of a "section".

We can probably do the same thing in the proposed template engine, i.e.
variables mentioned in outer sections are visible to inner ones, but not
the other way around. But sometimes you do want to refer to #TOTAL of
some section.

> modify the item details section of my HTML like this:
> 
>       <TD>$_quantity ($_quantity)<TD>$_price
>       <TD>$_description<TD>Subtotal: $_quantity * $_price
> 
> ($_quantity has the same value, it was only assigned once, and doesn't
> shift the array pointer)
> and the numerical multiplication value is substituted to accompany
> "Subtotal:". Now I'm not sure I like this "immediate evalutation" of
> variables in templates but it can keep the amount of code down. Then
> again, I think putting
> 
> 	Subtotal: echo($_quantity * $_price)
> 
> is just as good. Perhaps we can support both?

Perhaps this kind of stuff is better done in PHP script.

> My biggest issue is that yor propsal instroduces a dozen extra function
> calls which break away from already available PHP functionality. I mean,
> why have your own if/else construct? Use what already exists.

Believe me, I've thought about it. Problem is, what does regular PHP
parser know about "if #EVEN", for example (you mention it above too)?

> Why make
> your template (which is only going to work with PHP anyway), looks like
> some alian creature? If for whatever reason logic NEEDS to be in the
> template file, I don't have that luxury from the looks of
> things. Should I have to precompute everything and worry about
> getting variable order straight? I don't think so. (see 
> Subtotal: example)

Yes, I firmly believe that the PHP script should precompute everything
and just pass the values onto the template engine. It does place a bit
larger burden on the programmer to make sure that the values are
calculated properly and that variables are assigned proper values. The
proposed template language constructs are there to support so-called
"template logic" which has to do with how things are displayed, not how
they are calculated or processed. That's the job of the host PHP script.

Then again, you can always choose not to use 'if' statements and just
have plain templates with variable substitution. But from my experience
of working with designers they want that extra level of control that,
while completely independent of PHP script, allows them to format things
by themselves, without having to tap programmer on the shoulder each
time they want something done.

> Other benefits include not having to write your own
> parsing engine, adding "section" as a recognized keyword of the main
> parser is probably a whole lot easier. As is support for section only
> variables like #FIRST, and immidiate evaluation and output of
> variables. Third, your propposed process doesn't appear to handle more
> than a level or two of nesting and the implementation will likely be very
> hairy.

I guess we'll have to wait and see. :)

I've thought a bit more about how to have nested looping and I think we
can do that. Here's an example:

tmpl_assign("customer", array("Joe", "Bob"));
tmpl_assign("item", array(5858, 1295), 7333));
tmpl_assign("item_qty", array(2, 3), array(1));
tmpl_assign("price", array(29.99, 19.99), array(24.99));
tmpl_assign("descr", array("red shirt", "blue shirt"), array("green
shoes"));

This can be done pretty easily using tmpl_add_value() call, e.g.:

while ($sql->fetchRow()) {
	tmpl_add_value($id, "item", $sql->record["item"])
	tmpl_add_value($id, "item_qty", $sql->record["item_qty"]);
	etc.
}

If we add a call like tmpl_add_value_array(), then all you'd do is
tmpl_add_value_array($id, $sql->record) and it would automatically look
at the keys of $sql->record and figure out what variables to assign
where.

Going even further, if you have a data-structure like you described
above, perhaps, we can have a call that will take an array of variable
names corresponding to levels, and also the array of values and try to
deconstruct the tree in the appropriate manner, automatically assigning
variables. Example:

/* I belive that's the appropriate representation of your data structure
   up above */
$data = array(array("Joe",
					array(5858,
						  array(2, 29.99, "red shirt")),
					array(1295,
						  array(3, 19.99, "blue shirt))),
			  array("Bob",
					array(7333,
						  array(1, 24.99, "green shoes"))));

$levels = array("customer", array("item", array("item_qty", "price",
"descr")));

tmpl_assign_complex($id, $levels, $data);

This would go through the $levels and figure out what needs to be
assigned where.

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