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

On Mon, 27 Mar 2000, Ron Chmara wrote:
> Well, if they can indicate "on the third iteration, use a different bg color for
> the table cell", they wind up having some iteration influence...

Over the presentation of each iteration - yes, over the number and
content - no.

> It's a question about what one defines presentation _as_. Most of the trickier
> PHP problems that template logic would be designed to work with are not clear logic
> areas, or design areas, but areas where the two *mingle*. If, for example, a
> database search returns 5 records, 1,2,3,4,5, and the designer wanted them to
> _appear_ in a different order, with a few repeats, as 3,1,5,1,2,4,5, you now
> have the raw data component (1-5), and a designer who wants to "present" that
> data in a specific _order_.

I've been sitting here scratching my head and trying to figure out why
on earth the designer would need to rearrange data coming from database
like that, and.. well, I couldn't come up with a single example. It
_might_ be defined as presentation of content, but I can't possibly see
it being that useful.

> They don't want to control the programming of the
> presentation, they want to control the order they _appear_ in. Basically: Is
> the sort, the ordering of the data, a designer's perogative or a coder's
> perogative? Last I gazed through the spec, the template engine would require
> coder intervention for _every_ sort possibility. And it's not that rare that
> a designer would say "okay, I want to put a bar on top to allow the users to
> sort the results by ascending and decending date, author, and the other stuff".

From our experience, things like that are designed into the application
from the beginning, so the programmer would set up the sorting and
process the changes in the sort order. Of course, the template engine is
not going to do _everything_ for you. There will be certain cases when
it's better for programmer to step in and develop some things.

> > Assuming the programmer knows ahead of time that the designer needs
> > $standardhittext. Otherwise, the designer needs to come back to the
> > programmer and say, "Give me this variable".
> 
> Right. The logic must be known, and generated, by somebody. Your templates
> don't do this *without* PHP code, they use PHP code  to generate
> it.... so many of the template functions are really an intellegent aggregation
> of pre-built, generalized, logic. OO components, if you will.

If that's how you put it. It's simplifying many of the common tasks that
we have run across in our development experience.

> Again, you are now taking the data _presentation_ away from the designer,
> or possibly limiting the range of presentation to _only_ HTML formatting.
> By passing a variable on the numbering *style* to a function, the designer
> can now present that content in a manner to their liking.

We're thinking about how to make template engine more extensible so that
cases like this can be accounted for. One option is to provide some sort
of macro/mapping file that will map custom commands to PHP functions,
so that different numbering styles are possible. Another idea is to
allow embedded PHP for special circumstances, but I'd like to keep PHP
out of templates, if possible.

> Hm? I thought your engine was using regular expression replacement.

Not at all. It uses the same underlying tools as Zend.

> In order to put the HTML variables (<BR>,<B>,<Strong>) inside of a
> a presentation loop, you  have to be able to recognize them, or, if
> you _don't_, you just slam them in there with no validity checking
> (and guess who gets blamed when the tags break. :-)  ) I assumed
> you were doing validity checking somehow (to make sure your templates
> didn't have bad tags), but maybe you're just passing it _all_ through.

Validity checking? Of HTML tags? No, we're not doing that. The
programmers here don't slam any HTML anywhere - that's the HTML
designer's job.

> Now, once you have the HTML tags being inserted into the loop points,
> you're still lacking all the presentation areas that are "fuzzy" areas,
> areas where presentaion rules dictate some logic. Let's take a search results
> page for finding web pages, to point out what I mean about the
> problem of intermingling appearance and logic:
> "I want to always have the top result in bold"
> "I want to show the page results by modification date, author, name, etc."
> "Any results that are outdated, show it in a lighter font color"

These are good examples, and some of them would require PHP programmer's
intervention. But, in our company, for example, the programmer and the
designer get together when designing an application and determine if
different sorting/highlighting/whatever will be necessary. Then the
programmer can provide certain variables to the designer and also do
some logic for this.

> Yes. Passing tags into the PHP script, so the script can take the tags,
> and the data, and insert the tags as appropriate. Example: Bold
> the text in the first column of a table. In order to build that table,
> a PHP script needs to put that tag in there somehow. The design var
> (<B>) is inserted into the logic results stream...

Well, this particular example is solved in template engine as:

{if #FIRST}
	<b>{$result}</b>
{else}
	{$result}
{/if}

> MuWHAHAHAHAHA! Uhm....so now, everytime the content changes, somebody
> has to bug the programmer? Just like in your negative model, everytime
> the presentation changed, somebody had to bother a programmer?

What does "link this to PDF" have to do with content? If the PDF is
dynamically generated, then the link will just point to a PHP file.

> Well, it's about a designer having to learn syntax. Whether that syntax is
> @phone or $phone[] is one part of it, but here's the unfortunate other
> part (expressed in the proposed template language, but the same problem
> persists in all coder/designer variable passing):
> @phone, @phonenum, @phonenumber, @telephone, @telno, @voiceline, @voxline,
> @voice, @phoneno, @voxnum, @voxno ....
> The designer has to memorize the right variable and use it consistantly,
> in order for the coder to do anything with/around/on it. The designer can't
> just make up the variables whenever/however they want, neither can the
> coder. In order for the code to interact with the templates, variables have
> to be passed between the designer, and the coder. Thus, passing the vars.

I see where our problem is. In our applications it is the programmer
that makes up the variable names and sets up the skeleton templates with
minimal HTML structure. The designer then immediately sees what
variables are available and starts filling in the HTML stuff.

-Andrei
* George Orwell was an optimist. *