On 2004-01-28, Brett Sanger <swiftone-odjg+bCo0yxg9hUCZPvPmw@xxxxxxxxxxxxxxxx>
wrote:
>
> With H::T I would find myself having to revise the C::A application when
> a display requirement changed, which broke the whole concept for me.
> (Granted, our display requirements changed fairly often, but that's a
> buisness reality where I am).
>
> I use plugins for things like my left rail navigation (which is based off of
> database entries), site maps (full and partial), dynamically displaying
> links to files in a directory, or basically anything that isn't the
> central point of the application, but is display-based in nature. The
> templates remain very simple.
Looking at the TT plugins is where I start to get dis-illusioned with
the system. I several plugins for modules I already know how to use:
Template::Plugin::Number::Format
Template::Plugin::DBI
Template::Plugin::FillInForm
Heck, even:
Template::Plugin::HTML::Template
Maybe the cases you mention managing to be more design-specific. To me,
a number of these plugins look like the kind of examples of moving more
logic into the template that I'm hoping to avoid.
Instead, I prefer helper modules that transform data structures, and can
thus be useful with several templating systems:
Data::Grouper -- for formating DBI results into nested loops
Data::PageSet -- for creating paged results sets of data
Number::Format -- for formatting values.
I guess I'm still curious to see some actual code examples where TT
shines, without putting application logic into the templates.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive:
http://www.mail-archive.com/cgiapp-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail:
cgiapp-unsubscribe-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
For additional commands, e-mail:
cgiapp-help-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
|