making templates more integrated?

I am just learning about PHP having been spending some time studying the various "web" scripting solutions out there. In the course of my looking around I was duly impressed by the Python approach to templates (though rough) and thought there could be a more integrated means of doing things. I've been looking for a nice replacement to ColdFusion(tm) and PHP comes closest. Some of these may be simply an outgrowth of my very limited exposure to PHP so please feel to correct any invalid assumptions I've made. per va.php.net/~andrei/tpl-engine-spec.txt > The templates consist of straight HTML interspersed with template > language commands. There are a couple of way to specify the commands: ... 1. I think it's better to make template files look just like normal PHP files as far as grammar goes. In other words, don't introduce a special/custom series of tags/delimiters that are only unique to a PHP template that look out of place. eg {{<var>}} or {{* ... *}} but instead try: <?php $variable [<attributes>] ?> Now the question here is how does the parser know that it's supposed to do the equivalent of "print $variable" or not depending on if '$variable' happens to be in an enclosing body of code? I think it's a parser issue which should't be too hard to figure out: ie. if it's inside a code body, don't treat it like a template item. Or maybe "$$variable" is the special template case or something like that (ala shells). If the variable is a straightforward array it's pretty easy to iterate thru it. But what if it's an associative array? or a multi-dimentional one? What then? 2. comments would be the same as normal php comments. <?php /* */ or // ... ?> 3. Sections would be specified that 'section' becomes a keyword: <?php section [NAME=name] [ATTRIBUTES=attributes] { ... } ?> they should be nestable. They should not require names. each section has it's own instance of #FIRST, #ODD/EVEN, #LAST etc. 4. eliminate the if/then conditional stuff since the basic PHP grammar already knows these. 5. likewise with include/require(). So basically, the following example HTML/PHP file should be treated just the same as any other PHP file. It just happens to be somewhat simpler. In any event, I think it's incorrect to "patch on" this functionality when it more appropriately belongs in the parse engine. So, if you want to separate form from function it's just a short skip away from the current model. Have I missed something obvious? The developer's php script in pseudo code: <?php make a database connection; fetch some rows; $items_sold = 3 dimential array of customer, item and quantity include<template); ?> ========== The template you could hand your designers: <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY> <TABLE> <TR>put the column headers here</TR> <?php section NAME=_customer /* a couple of comments to help the HTML monkey */ /* first let's do customers */ if #EVEN <TR BGCOLOR="red"> else <TR BGCOLOR="green"> <TD>$items_sold[#INDEX]</TD> </TR> <?php section /* we're goint to putput the items that customer bought */ <TR><TD>$$items_sold[_customer.#INDEX][#INDEX]</TD> <TD>$$items_sold[_customer.#INDEX][#INDEX][0]</TD></TR> ?> ?> </BODY> </HTML> Now to me this is still not very nice and has many problems. In ColdFusion the developer would be handed a document that looked like: <misc HTML tags> <CFOUTPUT query=ThequeryName> <TR> <CFIF currentRow / 2 == 0> <TD BGCOLOR="red"> <CFELSE> <TD BGCOLOR="cyan"> #FieldName#</TD><TD>#Field2NAME</TD>... </CFTOUPUT> and he could play around with alternating colors and such. But again, it was only really designed to query output and one where we still knew the column names. php makes no such guarentees. Maybe that should be something that bears rectifying in the various database modules? The way the Python module did it was thus: #template spec# :pageTag [ <HTML><BODY> <TABLE> :paragraph1 <TR BGCOLOR=%s><TD>%s</TD> :paragraph2 :paragraph3 ] :pageTag2 [ :paragraph1 ] And then the Template() functions would be called such that: startTemplate(Page1); /* which would print up to ":paragraph1" and stop */ printTemplate(paragraph1, "green", "books); ... implementing just a simple case where the variables are simple arrays can be useful but it's not going to be very useful in the more complex casees. Logic is going to end up creaping into the template pages and that's what we were trying to avoid. Maybe the example I saw in Python is the way to go. (for simiplicity I'm only allowing 1 'logical' page per template file so that ":pageTag [ .. ]" is not necessary. Furthermore, the variables accessed within the "sections" must be simple arrays or scalars. So let's restate the proposed files: - developer's main php file (sales.php) - get some data from database; Template.load(sales.phpt) Tempalte.print(); // prints up to 1st section tag for i in $customers { // iterate thru our list Template.print("customer", $customers[0]); Template.print("items", $items_sold[customer], $items_sold[customer][item] ); // a kay/value array } Template.print(); // prints up to next 'section' tag or end of file - HTML template (sales.phpt> <HTML tags>...<TABLE> <?php section customer attributes = foo if #EVEN <TR BGCOLOR = red> else <TR BGCOLOR = green> <TD>%s</TD> ?> <? php section items attributes = foo <TD>%d <A HREF="itemdesc/%d.html"</A></TD> // or something ?> </TABLE> more closing HTML tags... Did that awkward, jumbled mess of thoughts make any sense? what do you all think? -- Network Security Technologies Inc. - Commercial support for OpenBSD www.netsec.net (703) 561-0420 matthew.patton@netsec.net "Government is not reason; it is not eloquence; it is force! Like fire, it is a dangerous servant and a fearful master." - George Washington