Re: [PHP Template] My template consideration

Manuel,

Regarding your comments on the logic in templates: maybe you are
misunderstanding the type of logic being added?

The logic that the designer needs control over is not the same logic that
the programmer has control over. It is kind of like "template logic" instead
of "programming logic."

The example Andrei gave was pretty good, where you are listing several rows
of data. There may be one row, there may be more. If there is only one,
don't print an <HR> on the screen, but if there are more, do.

In our experience, the programmers do not want to (and should not) be
bothered with having to take care of little things like this when the
interface is being put on. It is a waste of everyone's time. The designer
can put that in within a couple of minutes. But if we have to rely on the
programmer, the designer has to stop; talk to the programmer about fitting
this into his/her schedule; wait for the programmer (who is usually in the
middle of another project) to do it; then continue on. What should take 5
minutes, now has taken half a day.

Again, any logic that changes the program should definitely be handled by
the programmer. Any logic that simply affects the template itself should be
handled by the designer. Our programmers would shoot us if they had to worry
about a bunch of template logic changes all the time. And our designers
would shoot us too, because they would be getting frustrated waiting for
something the could do themselves.

Eric

on 2/20/2000 12:00 AM, Manuel Lemos at [email protected] wrote:
> 
>> I would disagree with this and so would at least our designer. Sometimes
>> the designer is best empowered by a few well thought out constructs that
>> she can use without going back to the programmer each time something needs
>> to be added to the template parsing.
> 
> Maybe I am not expressing myself properly.  What I mean is that only the
> designer should be editing templates. If the pages require any programming,
> that should not be requires to lay on templates because most designers are
> clueless regarding programming constructs.
> 
> The way I see it, the role of the designer is to prepare the visual
> presentation details, like the imagery and the layout.  Everything that
> requires managing programming logic should not be done by the designer even
> if he knows a little about programming.
> 
> If you put a designer doing a function that he is not best skilled at, you
> are looking for several kinds of trouble, like disputes in your team, jobs
> get delayed because the programmer more efficiently are done slowly because
> the designer has little or no idea how to do them properly and usually ends
> up copying and pasting some less than adequate solution borrowed from
> somewhere else.
> 
> So, why bloat the template engine with programming logic that would fit
> best in the base scripts?  Only if the programmer is meant to do everything
> and so there will be no disputes.  In that case you won't be separating the
> presentation from the content which goes against the initial goal of
> templates.
> 
>