[Catalyst] Caching problem?

[Brandon Black]

On 1/11/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Wed, Jan 11, 2006 at 03:13:58PM -0600, Brandon Black wrote:
> > On 1/11/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > > So long as you do it by setting MyApp->response_class and not by messing
> > > with Catalyst::Response directly :)
> > >
> >
> > You mean like this? :)
> >
> > ---------------------------------------------------------------------
> > package Catalyst::Plugin::Response::NoCache;
> >  ...
> > --------------------------------------------------
>
> MY EYES!
>
> > What's the "right" way to do it with response_class? Subclass
> > Catalyst::Request and set response_class to that from withint the
> > plugin somehow?
>
> Assuming "Catalyst::Request" was a typo for Response, exactly that. You
> could also consider not bothering with a plugin at all and having the standard
> way to use it be simply -
>
> use Catalyst::Response::NoCache;
> __PACKAGE__->response_class('Catalyst::Response::NoCache');
>

Yes, it was a typo.  But, while I understand it's not a wonderfully
kosher thing to do (sticking new functions into other people's
namespaces), the alternative doesn't seem so hot either, unless I'm
missing something (as usual).

If I subclass Catalyst::Response to build Catalyst::Response::NoCache
which adds the method ->no_cache, and someone else writes a similar
Request extension which adds a different method using the same
methodology, how is an application to use them both sanely at the same
time?  I mean, I guess they could write their own
Catalyst::Response::MyApp which does a "use base" on both extension
subclasses and then use that one as their response_class, but that
seems like an awkward thing for a user to have to do to use a couple
of optional extensions.

At least with the ugly namespace plugin, it layers with other plugins
like itself just fine.

-- Brandon