Re: [PHP3] template engine example document

Andrei Zmievski wrote:
> > So don't build different code for each web page! That doesn't require a
> > new syntax, that requires building generalized logic. We are rapidly
> > spiralling from the newish template debate into the old monolithic vs.
> > OO debate... and your code is basically _an_ OO set of generalized
> > logic, which, for some reason, you are passing using an new syntax.
> Hi, Ron.
> Believe me, there is nothing I'd like more than to make life easy for
> both programmers and designers (let's not go into exact definition of
> whta designer is for the purposes of this discussion).
> Knowing 'include' and 'echo' does indeed give the designer the basic
> power to create templates that are fairly functional, I suppose. From
> our experience, however, we have run into several situations where just
> echoing variables just might not suffice. Let's go through a couple.

If I find the variables to send to the logic, do I win? :-)

> 1. Suppose we have a template that prints out search results. This means
> that there is a portion of the template that needs to be repeated for
> every search result with different values being substituted. How do you
> handle that situation from your experience? Do you write a loop in a
> .inc file and then include it in the template?

I suppose you could do it that way, or if the designer specifies iteration, they
could write one include, and have the designer insert 5 includes. You might
want to offer them, in any case, variables for the appearance of the results...
The usual stuff, $fonttag, and the like. For iteration, you check a variable
that you initialize in your logic, or a designer supplied one. 
 
Here's a counter question. How would your templates allow them to, oh,
print resuts 12345  as  3151245? Your templates are getting
close to being standard function calls... do you allow them that far
into the logic, or is the purpose to give them *appearance* control?
Do they control *appearance*, or, as this debate  goes into syntax
wars, do they control *syntax* of those variables?

> 2. Maybe we want to print the phrase at the end of search results saying
> how many there were, e.g. "There was one hit", or "There were 5 hits".
> Obviously, this needs to be controlled somehow. Do you again put the
> logic in .inc file and include it?

<? include "dbresultcounter.inc" ?><---Result counter for db work, uses
the count function--->
There were a total of <? echo $resultcount ?> document(s) found.
OR
<? echo $standardhitext ?> <!---This allows for logic to control the
text varying between was/were hit/hits --->

Does your counter-controlled-by-designer-template allow them to
specify the numbering style? (one, two,1,2,I,II,)?  There is a point
of diminishing returns on when the loop logic leaves usability, as one
can no longer use it *without* becoming a coder. Which, I believe, is what
you're trying to prevent, but *as soon as your designers ask for more
features from the template*, you're back into PHP coders being called
back to the site everytime, not to modify the PHP presenation of data,
but to modify the PHP engine of presentation of data..... which is pretty
much the same thing. You're trying to jumpstart it by giving them
pre-defined "functions" that they can wrap in HTML (the loop seems
to be the most common one), but the hit you're taking is in evil
Grep madness, to get the variable tags.

Pass the html tags to the general logic, and be done with it. By the time
you've built all the logic, you have the function, only you don't have
*all the variables*. By the time you have all the functions available
in HTML coded into the PHP template-language-parser (<B>, <STRONG>,
<EMP> to pull into the template parser, you're still lacking the
_functions_ that designers will want the code to generate, so put
the tag control back into their hands, and set coders to work on
the functions themselves.

> These are not contrived situations, by any means, we encounter them time
> after time. I'd like to know how other people attempt to solve these,
> because Monte and I may be a bit set in our ways to see past what's
> obvious to us.

$fontag
$bgcolor
$tblcolor1
$tblcolor2

Etc. You're trying to get rid of a problem that occcurs when PHP
coders try to _put_ fixed tags into their code, but the problem doesn't
require new code, just different usage of the PHP code to let the designers
control *their* variables when it's nested inside of logic. When it's not
nested in the logic, it's not even needed. Think about how cascading
style sheets work, it's a good start to building pages based on variables...

Maybe you already have the following document: For each logic
block, what are the designer vars, and what are the logic vars?
Can design vars be put into the logic by the designer? Yes? Then
how? By a new syntax for a $var? :-)

> A rule that we try to follow is that there should be a central script or
> a collection of scripts where the main logic is concentrated. These
> scripts use templates for the presentation.

This is where it starts to break: Rather than having code independant of
programming, you now have programmed "templates". Counter problem,
again... the designer wants to use a different cascading style sheet for
their tags, _based upon_ a logic result, and not program the sheets. :-)

As you make the templates more complex, you rebuild PHP code to handle
each exception.  By focusing on what set of exceptions (coding in loops),
you're missing the very reason PHP got so big... because, well, when your
designer says "now, this link makes a PDF", or "this link searches
LDAP" you now have to again build everything _twice_. Once in PHP,
and once in your new syntax, to allow the templates to use a new way
of passing your vars.

> Then you should be able to
> swap one set of templates for another one and end up with a totally
> different look without touching anything in the main scripts.

Keep your variables consistant (which, I assume, you've had to do
anyways), and the logic is consistant. If you teach your designers
to use includes on a file, and that include specifies their global
(and/or local) visual variables, it gets even easier. :-)

> One
> template may have navigation var vertical, another - horizontal. One may
> have table rows with alternating colors, the other may not. With the
> system we built, it's achievable. How do you handle it?

Some components of a variable built site:
headerhoriz.inc <-horizontal bar graphic
headervert.inc <- vertical bar graphic
sitecolors.inc <- hex callouts for sitewide colors
ISOsectioncolors.inc <-local page color override of above colors
genericfoot.inc <- the generic footer for all pages
pgsqlresulttable.inc <-generic table loop built from results

See my other post for notes on how I program alternating colors
into a table, the colors a designer specified.

Don't rebuild lots of templates, or recode lots of pages... when you want
to change the color of all the site text (except for what they've overridden
locally), you change one *variable*. Not 30 templates, one, single, variable...
(perhaps a stumbling block here was that you didn't want them to use
includes?) If they want an item to appear in the html for all pages, they
can make a .inc and put it in there. They build the HTML blocks, coders
build the logic.... I think that might be why folks complain about the
current templates spec being too limited, because it is *page* level, not
component level. Of course, with my proposed method, you get both,
with PHP, and component based page building...want a whole page?

Make an include with all the required components. Pass standard
variable names. $searchstring gets used an awful lot. :-) Need custom
variables for a section? Make one include, with all the variables
for a given section.  Let the designers control the page vars, with the
coders controlling the logic vars. When you need to pass vars between
the two, do it in a standard manner.

-Bop

--
Brought to you from iBop the iMac, a MacOS, Win95, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.