making templates more integrated?
[email protected] (matthew patton) Mon, 28 Feb 2000 17:57:56 -0500 (EST)
| Newsgroups | php.template |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]
"Government is not reason; it is not eloquence; it is force!
Like fire, it is a dangerous servant and a fearful master."
- George Washington