Re: [cgiapp] CGI::Application::XML

[Darin McBride <suppressed>]

On November 24, 2003 03:39 pm, Jesse Erlbaum wrote:
> > And this, I think, is where many users have wished for C::A to be
> > separated from H::T.  Then it would make much more sense to graft XML,
> > H::T, Text::Template, etc., in subclasses:
>
> Sub-class, by all means.  But that shouldn't mean that the parent class
> is useless!  Think of it as a default.  In lieu of a more specialized
> sub-class, CGI-App uses CGI.pm and HTML::Template.  The hooks are
> already there.

While you're absolutely right that we /can/ subclass C::A to remove
this, there are a few points where some of us respectfully disagree
with your design choices.  I want to stress that I use H::T, although
not the way that C::A gives (it's not flexible enough), and I even more
want to stress that this is not intended as an attack on you, nor even
as a disagreement with the fundamentals of C::A (which are, IMO, an
awesome leap of design simplification).

1. Modules should do one thing, and do that one thing well.  C::A does
CGI application framework well.  It does not, however, handle cookies
well (although Mark is helping there).  It also does not handle
templating well.  H::T does templating well - in fact, in the way that
you and I both like best of all choices.  But we both know that other
users may not agree with that choice.

2. The compilation overhead of including all the H::T handling code may
not be huge, but it is not absent, either.  Subclassing merely means
that there is a chunk of code that is compiled on every invocation and
never used on any invocation.  Of course, code which is compiled on
every invocation and used on some invocations can't be avoided without
going through serious trickery (and would be detrimental to mod_perl
apps).

3. C::A and H::T are really quite orthogonal anyway.  Except for
TMPL_PATH in the constructor, the code that implements the runmodes are
completely independant of the code that implements the H::T support.  I
suppose this should be part of point 1 - the H::T support is really
something separate from the runmode support.

4. Nothing says that you can't have C::A::HtmlTemplate which provides
the default.  In lieu of a more specialised subclass, you can use this
one.  It can even be part of the distribution (it may sit on the user's
disk and never be used, but it also won't be compiled).

5. Withouth the H::T support, C::A is far from useless.  Far, far from
it.  Being focused on its core would probably be a good thing for its
users.

Of course, I think it's probably too late for many C::A users - this
type of change would break code (although if C::A::HT were part of the
distribution, the code change would simply be to add "::HtmlTemplate"
into the "use base" line of their applications...).  Which is why I
said I was considering a parallel module which would by its nature be
incompatable with C::A, and those who wanted to use it would explicitly
be breaking their applications that rely on the H::T support in C::A
today, rather than implicitly breaking simply by upgrading.


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed