Re: [cgiapp] CGI::Application::Light 0.1

[Darin McBride <suppressed>]

On February 14, 2003 01:30 pm, Cory Trese wrote:
> > Since my environment also uses TT (our use of plugins and other features
> > would render any H::T implementation a mass of nasty filters), I do
> > approve of the idea of decoupling CGI::App and H::T.  I'm also
> > interesting in CGI::Light, since I'm not doing any html generation from
> > CGI, but I seem to recall that  it removed a bit too much...  I'll check
> > again.
>
> We have found lots of valid ways to implement advanced features (like
> plugins) in HTML::Template.  These features have all been implemented
> (granted, some were suggested that we never tried) without damaging our
> careful separation of logic and presentation.
>
> I think many of the issues regarding complex functionality and
> HTML::Template are actually solved in the CGI::Application framework's
> design and the implementation of individual components (plugins, web-apps,
> ect).
>
> In addition to this, I am highly curious as to what makes CGI::Application
> 'coupled' to HTML::Template.  I have been working with both for over a year
> now, but have been using HTML::Template most of the time.
>
> Just my $0.002

C::A::L is very tempting to me because I've done something very similar 
already.  Rather than rewriting C::A without H::T "coupling", I've overridden 
all the coupling.

The unfortunate aspect of C::A is that there is really no need to have H::T 
functions in C::A except convenience.  You cannot return an H::T object from 
your run mode functions, you must call its output() function and return the 
H::T's output instead.

I agree with the other participant who said that we'd ideally have C::A 
without any H::T functionality, and then have a C::A:HtmlTemplate class that 
derived from C::A and added the H::T shortcuts, or another C::A::TextTemplate 
class that derived from C::A and added the T::T shortcuts, etc.  That way, 
those who don't use H::T don't need to have that code loaded/compiled.

All that said, I still use H::T.  But in its current form, the C::A shortcuts 
don't work the way I want them to, so I had to derive my own class, override 
all the C::A shortcuts, and waste the time/memory in loading and compiling 
the code I don't use.

Perhaps I've been on unix too long - I am starting to actually believe that 
one program (module) should do one thing, and one thing only, and do it well.  
It's easy enough to string together a number of programs (modules) to do a 
complicated task when each piece does its own job.


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed