Piers Cawley sent the following bits through the ether:

> <Cunning tag>
>   Perl code, no syntactic sugar, no restrictions, do wtf you like here
> </cunning tag>

> themes... [cue Leo and supporting N+7 digital platforms speech]

Ok, I'll keep this brief as most of it's been covered.

1) As mentioned: TT separates design from code and code from design. This
means that designers are responsible for design logic and coders for
functional logic. This is GOOD.

2) TT does require designers / HTML'ers to learn some stuff, but it empowers
them without them having to learn (or even getting the chance to break)
perl.

3) Versions of a site / system (e.g. different skin/design) are easy to role
out, be it a new look / version for digital TV / print friendly pages / wap
/ xml / email / postscript!! (Talk to Andy). Alterations to the code do not
require editing code on 101 different pages to add new functionality and
this decreases technical maintenance dramatically.

4) Standard methods / functions (such as page numbering) become modules
which with one line of code (either in the code or if you have to the
template) are instantly available and you are not reusing the wheel.
Creating such standard approaches mean's that designer/HTML'ers always know
that [% page_info.current_page %] is the number for this page. [% FOREACH
record = results.holiday %] will always give them the results for holiday.
We also made a module to do date conversions, to tech's only had to supply
it in MySQL date format, the design/HTML'ers could then choose how it was
displayed and much time was saved.

5) Code and development time in my experience is cut by 1/3, as there is no
design logic.

There are many other reasons, but these are the core of them. It (as with
everything) depends on your situation and requirements. Personally I can't
think of ANY reason not to do it this way, even if your
only doing a single page, you will save time AND future proof the system all
in one fell swoop.

</not so brief after all>

Leo

Reply via email to