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

From: Date: Mon, 27 Mar 2000 16:21:28 +0000
Subject: Re: [PHP Template] Re: [PHP3] template engine example document
References: 1 2 3 4 5 6 7 8  Groups: php.template 
Request: Send a blank email to php-template+get-477@lists.php.net to get a copy of this message
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. > They don't. PHP does. They have placeholder code for tags, they don't care > what goes in that placeholder. Is it that the coder inserts the placeholders that > bothers you? You'd rather the coder and the HTML person had to pass their code > through another piece of glue to attempt to assemble the pieces? > > In a large scale project, a designer _cannot_ view every page, code every break, > that's just plain unworkable. "Here, go to the website, and proof the 80,000 > possibilities of the template results". Hence, they must operate within boundaries of > what presentation is controlled manually, and what presentation is built > out by logic. > > In the DTP world, these are called 'styles". The designer cannot proof every > page of an 800 page manual, so they proof the *style*.... this is another reason > folks working in this flexi-template mindset have to build so many templates, > as it is encouraging page proofing at the _page_ level.... I know you've > considered this much, otherwise you wouldn't be working on templates, but > once the template is _logic_ driven, it is outside the realm of what they can > manage and design. Most designers don't even _want_ to proof every iteration, > they want to set the general appearance style, and let the text and copy flow > into that. (In the DTP world, page layout is one of the lowest on the food chain, > as they don't direct appearance, they whack content into appearance, for the > companies that lack automated workflows). So they state the iteration > (for my workflow, a master $var or override $var), and the page rendering > is done by the PHP engine. In your workflow, you add a new syntax for > the master variables, with some(?) local variables, parse once through your > template engine, and parse again through PHP? I come from a print > world, so this is why I focused on master, and local invocations, of styles.... > > I can only assume that the preffered direction for Web design was similar, > so maybe that's another direction to pursue? A "style sheet" for a section > of content, a "master page" for overall content.... I have presented the concept of > style sheet object as a variable, wheres your workflow tends towards > master pages, *without* dynamic style invocations... > > 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. I'll just explain a bit about the example. The structure is: article.php paper.php demo.conf templates/ header.tpl front.tpl footer.tpl article.tpl The first script is 'paper.php'. It gets content (in this case, just from arrays, although it could be just as easily from a database) and creates content variables that get passed to the template. 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. It simply goes through the variables passed by the script and prints them out. Along the way it does some checks, for example, if #EVEN is true then it prints one table row background color, if not, then another. It also checks to see if tagline is empty, and if it is, then it does not print it and the <br> in front of it. Notice 'sectionelse'. If there were no values passed from the script for headlines and taglines, then the portion specified after 'sectionelse' would show up. The 'header.tpl' template also loads config file, albeit a different section from it so that DEFFONT in "Common header" section of config file overrides DEFFONT specified in config file globals. 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? -Andrei If you find a job that you love, you'll never work another day in your life. - Mark Jackson

Attachment: [application/x-tar-gz] ron-templates.tar.gz
« previous php.template (#477) next »