On 9/26/01 2:32 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl <[EMAIL PROTECTED]> writes:
>
>> I believe that a designer shouldn't modify anything objects used in an
>> application, and again it's my opinion but I don't buy the template engineer
>> designation.
>
> I doubt all the template engineers at CollabNet would like that much.
What I meant is that most template engineers have Java experience and are
gaining more all the time. That a template engineer is really a java
programmer. It is basically programmers working at the template level and as
such constructs which I would consider part of the model make there way into
the view in being part of the template. It was in no way meant to deride the
designation of template engineer, my apologies if that's what came across.
My point was that alteration of the model from within the template to me is
a violation of MVC but is deemed all right by Jon because it's a 'template
engineer' doing this. That's the part I don't buy. Hand those templates
you've worked on to a designer and I think you would be pretty much hosed.
Some just can't understand and the talented one's don't really feel it's
their job to have to deal with any logical constructs.
I typically work with designers who have zero programming experience and as
such the templates have as little to do with programming as possible. I have
found in my personal experience that designers are not incapable of learning
things like #set, #if/#else/#end but they don't want to and don't care.
They just want to design. I basically have none of those constructs but I
admittedly have not been able to get rid of #foreach.
If you're going to put model/logical constructs in your template that's
fine. My gripe is the invention of the template engineer designation which
somehow makes it all right to still call that part of the view. If you
cannot hand those templates over to a designer and have them understand it
than I think you've violated MVC and this usually entails logical constructs
which in some way or another change the model.
Usually templates I make now, that are handed off to designers, can be
understood with a cursory glance at the Velocity docs. Some of my earlier
templates were considered by the people I worked with to be difficult to
understand and the designers felt uncomfortable changing much because they
weren't sure what was what. Again these designers are not dim, but they are
completely disinterested in things like
#set ($customer = $tool.getCustomer($id))
I remember talking to a guy at the servlet expert group @ java one and he
said he thought velocity sucked because it would totally confuse designers
and it confused the designers he worked with. I think the confusion can be
limited but any form of logical construct in the template can be confusing.
You are fortunate at collab that you've got many bright minds and are keen
to tinker with the templates. But the people I work with could care less and
complain if more than a #foreach or $variable reference have to be dealt
with.
Again, I was in no way making any sort of derogatory remark about template
designers I just asked that they been seen as what they are: people with
some java experience even if it is slight. People who are comfortable making
changes to the model from within a template. But I would venture to say that
most template engineers have more than a little java experience.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
