[cgiapp] strategies for decoupling HTML::Template

[Berg, Eric]

I think of HT as a nice freebee that's pretty transparent and
inexpensive to install (pure Perl, etc.) and relatively unobtrusive.  I
don't use it, but it's been used here before I came in and put a TT
stake in the ground.  I've been using TT for a number of years now, and
am comfortable with its installation requirements.

What is it that is really at issue here?

Why does anybody care if this realtively benign package gets installed
by default?  Ok, it breaks the all-must-be-as-modular-as-possible rule,
but...big deal?  Surely, noone feels slighted that their favorite
templating libs weren't chosen.  

TT works just fine with CA.  Doesn't it?

And finally, Jesse's needs (he uses HT) and the potential impact to
users going forward that would come from uncoupling C::A and H::T would
probably be more of a pain that it's worth in general.  

So, again, now that we've been all over this, what's the rub here?

Eric



-----Original Message-----
From: cgiapp-bounces at lists.openlib.org
[mailto:cgiapp-bounces at lists.openlib.org] On Behalf Of Timothy Appnel
Sent: Monday, October 22, 2007 5:46 PM
To: CGI Application
Subject: Re: [cgiapp] strategies for decoupling HTML::Template

On 10/22/07, Jason Purdy <jason at journalistic.com> wrote:

> H::T is a simple and fast templating engine that enforces strict MVC, 
> too.

Simple, yes -- to a fault.  In my experience, I find what constitutes
the parts of MVC to be subjective. I haven't heard much of an argument
about what belongs in the model so much as I heard a lot of debate about
what constitutes controller logic and what belongs in the view.

My opinion is shaped more by practicality then idealism. In my
environment interface/experience designers are totally different people
and skills. (There are those who would argue this shoudl always be the
case, but I recognize this is not always practical either.) It's
annoying to have to keep going into my code to tweak the formatting of a
date value or calculate conditional logic down to a boolean value
because the designer changed their mind. It's equally as annoying (and
wasteful) to have to build and stash all of these values from an object
that already contains all of that just in case the designer needs. So to
me H::T excludes a lot of what I think should be in the view. Its for
this reason that why H::T had to be decommissioned in MT4. The
conversion of reading with objects and their methods (calculated values)
is not complete, but it's going to reduce the amount of code in run
modes a great deal and make the logic in the views much more reusable.

I guess my point here is that there are different needs that its rather
pointless debating who is right or which template engine is better. Its
a shame CGI::App made that decision and it would be nice to think that
there was more community spirit here then the hard line Jesse took, but
things could be worse.

<tim/>

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.