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

[email protected] (Ron Chmara) Tue, 28 Mar 2000 12:31:06 -0700
Newsgroups php.template
Message-ID <[email protected]>
Andrei Zmievski wrote:
> 
> On Mon, 27 Mar 2000, Ron Chmara wrote:
> > 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.
> And who should be inventing new variables?

Site architect or the lead programmer. Line programmers inventing their own variables
leads to lots of programmers arguing over "proper" variable names. It doesn't matter
much in a small company, but on large scale projects, passed variables need to be
consistant, and publicly known.... hence, line programmers don't create their own
variable names.

> > Heh. I thought you kept your designers _out_ of logic? They're doing
> > IF/ELSE statements? So much for not needing programming. :-)
> The goal is to keep them out of content, mostly. Our designers, for
> example, would raise hell if they couldn't do a simple 'if' here and
> there.

:-) I guess that's a designer issue. Mine don't "lower themselves" to
doing logic...

> > Well, you dump the if's and the looping
> > on the *designer*, and all you do is make a simplified syntax!
> No one is dumping looping on the designer.

<IF>
 @LOOPOBJECT
</IF>

> > 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.
> Ok, you proved it's technically possible, but logistically? My god, I
> can't imagine having to write "articlecheck.inc" for every looping
> construct or to split out all the little pieces into a miriad of .inc
> files. That's unworkable both for me _and_ for the designer. We've tried
> it, trust me.

OO vs. Monolithic. It's a nightmare the first time, the second time ain't
much better. The 5th time, you'll wonder how you ever lived without it,
*provided you get the logic division right*. :-) Actually making the
components reusable is the programming challenge, so in many cases, Brooks'
law comes into play.

Here's the real payoff: For simple pages, like the article example, there
isn't much of a gain. Of course, the article pages don't have 3 Nav bars
with dynamically generated content, dynamic javascript built from db
content, a team of 15 content generators changing their objects, 3 web
designers changing their page pieces... it's only ugly when the pages
are simple. For building up a 60 page site in 3 days, it's *indespensible*
to build sites as reusable components.

It addresses an area that the templates don't: When there are 4 designers
for 6 sections on given page, how does templates make their components
individually accessable, and protected?

-Bop

--
Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625
laptop, currently running RedHat 6.1. Your bopping may vary.