Re: [PHP3] template engine example document

Monte Ohrt wrote:
> Hello Ron,
> Ron Chmara wrote:
> > Monte Ohrt wrote:
> > > Sometimes there are logic changes that only affect presentation, not
> > > content.
> > Ah. That would be a disagreement on whether or not the designer even
> > _has_ access to the logic blocks...
> They _only_ control presentation logic.

Yes, the HTML that is _wrapped around_ the data.
What wraps that HTML (lets see how fine we can split this hair, eh?)?
PHP variables pulled out from a template doc?
So why not make the template doc out of PHP variables, instead
of another syntax?

No matter how you slice it, you are using PHP variables for your
HTML code wrapping. I'm advocating that the coders see their variables,
so when it breaks, they can fix it.

> I think we have conflicting interests: You say designers should not be involved with
> logic, we say programmers should not be involved with layout. Our programmers cannot
> possibly anticipate the designers every need, this is just not workable.

You don't *have* to. Much like your template parser looks for surrounding/mixed
tags, _without the coder knowing what the tag is_, PHP without your abstraction
layer can do the same.  You are wrapping the php code result in a designer
indicated tag. The coder doesn't care what's in the tag. I am wrapping the result
in the tag, without caring what's in the tag.

In my forkflows, it _doesn't matter_ who codes first, after the base format is
set. The coder doesn't care what HTML goes in the HTML variables. They just spit
code from databases into controolled logic, which the designer has determined
the appearance of. :-)

> 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.

> There should be no need
> for the programmer to be involved with adding HTML tags (or anything else) to the
> content. That is the designers job in the layout.

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?

> > Part of your example set seems to indicate that they are
> > even going so far as to arbitrarily define the logic of presentation,
> > but that breaks the designer being kept from the logic.
> ... and you break the concept of programmers not being involved with presentation.
> If the programmers have to pass HTML intended for presentation, we've just added
> unneeded development cycles to the project.

Why? The HTML is not something the coder looks at or works in. Do you
also not have your coders passing content variables, because the content folks
"now have to reproof  the content, because the coder is passing that
variable?" That's, well...silly.

> The designer may not end up doing
> something just for the fact that the programmer must now be involved to make it
> happen.

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.

> For instance, the designer can
> present every other row (or the 60th row, whatever!) with a different color. They do
> not control how many times the loop is iterated, that is already determined by
> contents sent.

So, when the contents sent are a 14,000 line result.... :-)

-Bop

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