Re: [PHP Template] Re: [PHP3] template engine example document

Hi Ron,

This solution would technically work, although it's going to make it
hell for a designer to work with templates. In the currently proposed
template engine, the templates relatively resemble the final output.
With the solution given here, you have just fragmented a single page
into lots of ".inc" files, which will make a designer cringe. I speak
from experience on this one, we ran into this same situation with
FastTemplates. We had complex html pages strung out over many files and
this was unworkable for the designer.

I know there are some exceptions like breaking headers and footers into
include files. Designers don't seem to mind this one. Generally, each
page uses the same header & footer, so they don't need to visually see
this on each template.  But breaking out every little piece of logic
that needs a special html tag, looping, etc... that quickly turns into
an unmanageable mess of files.

Are there other designers out there that can relate to this, good or
bad?

Monte

Ron Chmara wrote:
> 
> Andrei Zmievski wrote:
> > On Sun, 26 Mar 2000, Ron Chmara wrote:
> > > > Again with your concept, the programmer involved in layout.
> > > No, they just use the variables that were set out for them, without ever knowing
> > > what those variables are.
> > The programmer uses variables that were prepared for them? By whom? That
> > wouldn't make much sense.
> 
> Well, the line programmers shouldn't be arbitrarily inventing their own variables,
> EVER. There has to be some form of consistancy. In this case, the variables are
> known, site wide, by the page designers, and the PHP logic coders. $tblcolor is
> something a PHP coder doesn't own, it's not their variable. It's the designer's.
> 
> > > All of this to wrap PHP results in HTML tags? I'm beginning to think
> > > that both our viewpoints need to be changed, as we're not getting to a "clear,
> > > and simple", endpoint, for the mere functional equivalent of teaching
> > > a designer to "printf" inside of a loop.
> > Maybe what we'll help us understand each other is an example. I made a
> > small PHP script/templates example that uses most of the features of the
> > template engine and attached it to this message. It's about 1K, so I
> > think it's fine if everyone on the list looks at it. What I'd like you
> > to do, if you can, is change that example so that it conforms to
> > whatever standards you follow. That way I can concretely see what you
> > mean by design vars/logic vars and other stuff.
> 
> Sure. It's pretty much the same thing as yours, with a different syntax.
> 
> > The template for this is 'front.tpl'. It uses config file 'demo.conf' to
> > load some values (like colors and fonts). Variables with '%' prefix are
> > these config variables. Then 'front.tpl' includes common 'header.tpl'
> > and 'footer.tpl'. The we have an "article" section/loop there.
> 
> Heh. I thought you kept your designers _out_ of logic? They're doing
> IF/ELSE statements? So much for not needing programming. :-)
> 
> > It simply
> > goes through the variables passed by the script and prints them out.
> 
> $variable, not %variable. :-)
> 
> > The 'article.php' simply processes the incoming ID and displays the
> > article. Same concepts apply.
> > That's about it. Care to come up with an example of how you would do it?
> 
> Attached inline. You'll notice that I fixed the syntax to be PHP syntax, so
> your variables are now, well, PHP variables:
> -----
> //demo.conf
> $TITLE  = "Template Demo"    ;
> $QEMAIL = "[email protected]"  ;
> $DEFFONT = "arial,helvetica" ;
> // ## end globals ##
> //[Front Page]
> $HEADLINECLR = "color=\"#008000\"" ;
> //[Article Page]
> $ARTICLETITLE = "Article Page";
> //[Common Header]
> $HEADERDEFFONT = "courier";
> $tblcolor1 = "FFFFFF"
> $tblcolor2 = "EEEEEE"
> ?>
> ----
> 
> See? You are changing the syntax of variables. Nothing different about that.
> Why learn two separate variable syntaxes?
> 
> ----
> <? include "demo.conf" ?>
> <?/* Setup some data, this might as well come from a database */
> $articles["Headlines"] = array("GM Gets Flying Car",
> "Solaris Runs On Amiga", "SQL for Dummies");
> $articles["Taglines"] = array("Going To Lunch Is Really Fast Now",
> "Many ask Why?","");
> /* Load the template */
> 
> //$id = tmpl_load("templates/front.tpl");
> /*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/
> //
> // This is part of the unneeded syntax duplication steps.
> // The "template" file is basically simple page components,
> // Using standardized variables.
> //
> //
> /* For each article, append the variables */
> //
> // Why? easier to change the vars, then spit the page back to browser
> // Since this has a "for" loop, I assume this is in programmer space.
> //
> // This one step is what has made this uneccesarrily convoluted. IMNSHO.
> //
> 
> for ($i=0; $i< count($articles["Headlines"]); $i++)
> {
>         $HEADLINE = $articles["Headlines"]);
>         $TAGLINE = $articles["Taglines"]);
>         $ART_ID = $i);
>         include "articlelayout.inc";
> }
> ?>
> ---
> 
> So far, there's designer set up variables, the .conf file, but
> what about the page logic? Well, you dump the if's and the looping
> on the *designer*, and all you do is make a simplified syntax!
> I'll try to make it easier on them, as well, since this is logic
> driven by their design:
> 
> ---
> //articlelayout.inc
> <?
> include "demo.conf";
> include "header.tpl";
> ?>
> <FONT face="<? echo $DEFFONT ?>" size=+2>Articles</FONT>
> <P>
> <TABLE border=0 cellpadding=10 cellpadding=5>
> <?
> include "articlecheck.inc"
> include "article.inc" ;
> ?>
> </TABLE>
> <? include "footer.tpl"; ?>
> 
> ---
> >From the above it forks:
> Article check runs, it checks for an article, if none is found,
> it exits, drops in the </TABLE>, the footer, and closes the HTML stream.
> Remember, my designers know what an include is. :-)
> ---
> //article.inc
> <?
> //      {if #EVEN}
> //              <TR bgcolor="{%TRFIRSTCOLOR}>
> //      {else}
> //              <TR bgcolor="{%TRSECONDCOLOR}>
> //      {/if}
> 
> include "tablecolourswitch.inc";
> 
> // this is why one uses global table color variables. This
> // table colour switch never has to be coded again. :-)
> //
> //                      <A href="article.php?art_id={@ART_ID}">
> //                      <FONT {%HEADLINECLR}>{@HEADLINE}</FONT></A>
> // This is another syntax switch on your part. see below... I used
> // echo statements, assuming that you're not using PHP4 or ASP tagging
> // yet.
> 
> ?>
>                 <TD>
>                         <A href="article.php?art_id=<? echo $ART_ID ?>">
>                         <FONT <? echo $HEADLINECLR ?>><?echo $HEADLINE ?></FONT></A>
> 
> <?
> // Okay, now you have allowed them to make an "if" decision in their
> // coding page, in addition to a while loop (the @). I would handle this
> // one of two ways. the first would be to have them hand this off to
> // somebody who did logic, the second would be to do as you have done,
> // and teach them a basic logic construct, the "IF". They already know
> // how to echo. If the logic was complex enough, I'd fork the logic
> // blocks again into more includes...
> //
> // Of course, this now means that your designers are now doing programming
> // logic. :-) I realize that may rub some coder egos the wrong way, so call
> // it "interface logic" or something
> //
> //                      {if @TAGLINE}
> //                              <br>{@TAGLINE}
> //                      {/if}
> 
>                         <? if ($TAGLINE != "")
>                                 {
>                                 echo "<br> $TAGLINE";
>                                 }
>                         endif
> 
> // Now, that isn't so painful, is it? They open and closed an
> // if, used a variable, all of which you have them doing as
> // well, with a different syntax.
> 
>                         ?>
> 
>                         <hr noshade size=1>
>                 </TD>
>         </TR>
> 
> <?
> // I don't need the else section, that's handled before it begins
> // doing article.inc. The loop is already handled in the programming
> // section.
> ?>
> ---
> 
> Does this make it more obvious for you? By setting up the concept
> of designer logic, and coder logic, and keeping separate files, your
> template spec led you to recreate PHP, albeit with a modified syntax.
> You can maintain the designer logic, and coder logic, as separate
> files, with the designers doing simplified logic in their files (which
> you are calling templates). For iteration, you recall the same file,
> and with a decent amount of RAM, your overhead is only for the file
> from buffer....
> 
> Of course, the more complex the presentaion logic becomes, the more
> constructs it requires, so you wind up with limited languages like
> a subset of PHP... which can be accomplished by only training them
> in what they can handle, without building another language, with a new
> syntax for loops.
> 
> -Bop
> 
> --
> Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625
> laptop, currently running RedHat 6.1. Your bopping may vary.