Justtechjobs.com Find a programming school near you






Online Campus Both


php3-list | 200003

Re: [PHP3] template engine example document From: Monte Ohrt (monte <email protected>)
Date: 03/26/00

Hello Ron,

Ron Chmara wrote:

> Monte Ohrt wrote:
> > Ron Chmara wrote:
> > > Not at all. There is no limit to how many HTML pages can call the same logic
> > > block. If the logic _features_ change, then in both of our methods, the
> > > programmers have to rework the pages. I'll give you an example: The server-
> > > wide credit card validation logic is one, and only one, file. It never
> > > has to be duplicated, never seen by the website designers. The most a
> > > designer has to do is add an hidden form variable, or build an HREF on
> > > a page, (both are things they're fairly knowledgeable about) and on
> > > the next page, know the syntax for an include, and decide
> > > where to put the result. So adding dynamic content means they need to
> > > know all of *two* statements.
> > 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.

>
>
> > For example, in one template the rows alternate colors, on
> > another template they do not.
>
> Then the designer gets two variables, that they can use, or not use.
> $tblcolor1 = ""
> $tblcolor2 = ""
>
> If they want two colors, they assign two. If they want one color,
> they get assign one. They don't _do_ any logic that way. The logic
> looks for two vriables, if there are two, it alternates. "But what if
> there are 60?" Find a better designer. :-)
>

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.

>
> > For another example, you want a <BR> tag
> > in front and in back of the title, unless the title is blank, then print
> > one <BR> only.
>
> They can pass HTML tags in variables. That's nothing new, either..
> if you want them to always be based on a ruleset, you can implement it,
> but a designer shouldn't _be_ specifying what those rulesets are,
> arbitrarily. Their land is arbitrarily controlling appearance, no?
> So give them control of their variables.
>

Again with your concept, the programmer involved in layout. 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.

>
> > Then in another template, you want NO <BR> tag if there
> > is no title. How is this taken care of with the same logic, different
> > templates?
>
> Designer driven:
> $title = "This is my Title";
> $title = "<BR>This is my Title<BR>";
> $title = "<BR>";
> *Or (Logic driven)*
> Page one (requires more standard logic blocks):
> include "standardtitle.inc";
> include "sales-sub-section-title.inc";
>
> You are talking about the designer having variable input into the page
> appearance, so it seems natural to make that into, well, variables, not
> logic. Logic shouldn't be _part_ of the appearance. If the designer is
> chosing from logic components, they are choosing their template
> _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. The designer may not end up doing
something just for the fact that the programmer must now be involved to make it
happen.

>
> I think part of our respective, differing, mindsets is that you are assuming
> that the designer has a template with mixed logic and appearance that
> they control, with the designer setting the loop iteration counts (don't
> do that, you'll regret it when they look up 30,000 records for one table).

No, the designer does not control loop iteration counts, the programmer is
responsible for how much looped content is sent to the layout. The designer can only
control the appearance of the content that is passed. 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.

>
>
> I'm approaching this with a mindset that designers shouldn't be allowed to
> control loops, only the resulting, final *appearance*.

Exactly!

>
>
> > > 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.
> > Well as in the examples I gave above, I'd like to know how these
> > situations can be handled through "generalized logic" that the designer
> > does not see. There are other situations with looping content too.
>
> Loops are logic. Designers shouldn't be _doing_ logic, should they?
> If there are loop variables that they can specify at their discretion, offer
> them, but that's no reason to fragment PHP.
>
> -Bop

See above, they do not control loop iteration, only the appearance.

Monte 

-- 
PHP 3 Mailing List <http://www.php.net/>
To unsubscribe, send an empty message to php3-unsubscribe <email protected>
To subscribe to the digest, e-mail: php3-digest-subscribe <email protected>
To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
To contact the list administrators, e-mail: php-list-admin <email protected>