On Fri, Jun 07, 2002 at 11:22:13PM -0400, Jesse Erlbaum wrote:
> >I'm a huge fan of passing Date::Simple objects, which can then take a
> >strftime format string:
> > [% date.format("%d %b %y") %]
> > [% date.format("%Y-%m-%d") %]
> Out of curiosity, at what point of flexibility do you feel it is OK for your
> designers to go back to the programmers? In your book, where does a bit of
> flexibility "cross the line"?
I think that will depend both on the organisation, and the case in hand.
Most organisations I've worked with have much stricter change control on
work by programmers than designers. As such, things which are purely
presentational and can be achieved fairly trivially by a designer with a
small amount of effort (such as the date example above), compared to a
request/develop/test/review/integrate code cycle, should always be in
designers' control, where possible.
In this case, even if you haven't got that level of separation, or of
process, I'd still say that it should go to the template (how a date
_looks_, rather than what the date _is_ is always a display issue IMO).
But there are many examples where things aren't so clear cut.
I firmly believe in laziness, so my general rule of thumb, even when
working on personal projects where I'm doing the code and the templates
myself, is to imagine that there is a team of designers, and that I'm
the only programmer. Then I imagine that this team of designers report
to a committee of PHBs who keep changing their mind on how everything
should look. Then I try to ensure that I can minimise the amount of
things that the designers end up having to come back to me for!
Maybe I'm lucky with the designers I've worked with - but in general
I've found that designers are happy to learn things like basic strftime
formatting, or the basic control structures etc of something like Template
Toolkit if it means they can get their job done on their own terms,
without having to keep coming back to programmers and asking for simple
changes that'll probably go on a list of things to get done sometime.
I think this crosses the line when it goes against the laziness
principle in the other direction. It's just as bad if a business
decision means having to change 50 templates as if it means having to
change 50 perl modules.
TT is fairly unique in my experience of templating systems in that it
allows you to fairly simply have many levels of abstraction in the
templates too. I would always set up a macro for something like
"page_title" - even if at this stage that just translates into an H1 of
a certain class which can by styled with JavaScript. Then, if you want
to do something with it that can't really be done with JavaScript,
you're still only needing to change one template. You can build up quite
a library of abstractions fairly quickly.
Basically this is all a long winded version of saying "it depends" :)
I'm happy to pontificate on various scenarios if you want to throw any
out, though!
Tony
