#3 logic tags

[Andreas Demmer]

P.E.T. should be extended with the following features:

IF / ELSE construct to allow costumization of html
layout and design depending of its content

LIST tag making it possible to have every second line of
a table an alternating color, making the table easier to
read

[Haig Evans-Kavaldjian]

Logged In: YES
user_id=764385

I would suggest also that the proposed IF tag provide some
way to test...

1. The presence or absence of a particular content element.

2. The fact that a particular content element is or is not an
array.

3. The total number of elements in an array content element.

Specifically, when I was developing my own first (horribly
bloated and programmer-unfriendly) templating system, one
of the most useful things I found for HTML output is the ability
to include or not include not only many <TR>s representing
the rows of an array content element, but also, just as
critically, a leading <TABLE> tag (or even more) and a
trailing </TABLE> tag surroudning the table rows, but only if
there *are* rows.

[Haig Evans-Kavaldjian]

Logged In: YES
user_id=764385

One other thing I would suggest is that you may want to
provide a way for examining (and outputting) meta information
during template processing -- for instance, to be able to
report how many levels deep the engine is in the content
array, what row of what total number of rows in the current
content element the engine is currently processing, the total
number of top-level elements in the content array, and so
forth.

Essentially, I suppose, I am suggesting that the processing
engine have a sort of "self-inspection" capability, an ability to
examine the entire content array at any time, not just be
focused strictly on the one content element being processed
sequentially at any given moment.

[Haig Evans-Kavaldjian]

Logged In: YES
user_id=764385

Now I remember!

At some point I think I decided... "Hey, wait! Isn't PHP itself
really an elaborate templating engine?!"

Sure, we use it for much, much, more... the Model and the
Controller in MVC parlance... but with careful program
design, it is also quite easy to complete the separation of
View, too.

What I often find myself doing is channeling all program
access through a single script (the Controller), which
examines the passed in parameters (query terms, POSTed
data, attached files, cookies, etc) and then calls an
appropriate Model script via include(), which in turn builds a
content array that is then rendered by an appropriate View
script, again via include().

The only disadvantages are...

1. ...that there's no clean API between the View and the
other two parts of the MVC structure -- no simple,
straightforward templating language; and...

2. ...there is a risk that someone will be tempted to do
important processing (perhaps things that should or do affect
the Model or the persistent backend data) in the View code.

But the really great advantage of this scheme is...

1. ...that the full power of the PHP language and its rich
libraries are available in the View part of the structure, rather
than a limited, pared-down templating language.

Any opinions?

[Nobody/Anonymous]

LIST

for($i = 1; $i <= 12; $i++) {
$loop = $template->addLoop('loop');
$loop->number = $i;
$rule = $i % 2 ? ' class="ruled"':'';
$loop->rule = $rule;
}

.tpl

[loop]
<tr{rule}>
<td align="right">{number}.</td>
<td>Name</td>
<td>Discription</td>
</tr>
[/loop]