[Catalyst] Caching problem?

[Brandon Black]

On 1/13/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Fri, Jan 13, 2006 at 03:25:00PM -0600, Brandon Black wrote:
> > Attached is a draft of a patch against trunk.  It generalizes the
> > concept for plugging into any component (Request, Response, Engine,
> > Dispatcher, etc, although I can't think of how or why people would use
> > the last two yet) using plugin_for as above.  Also added a section to
> > C::Manual::WritingPlugins with an example for plugging into Response.
>
> I don't think that's going to do what you think it's going to do. What you
> want to do is if (e.g.) plugins are found for Response, auto-create
> MyApp::Response isa <responseplugin>, Catalyst::Response and set the
> appropriate foo_class to MyApp::Foo. I'm pretty sure what you're currently
> doing will add stuff to either Catalyst::Request/Response itself and/or
> get an empty class from the foo_class accessor and add stuff to MyApp.
>

It does function correctly, it's just a matter of style and/or
correctness (I've tested a couple of simultaneous Response plugins
using the patch).  It does directly add base classes to
Catalyst::Response and friends (or more precisely, to whatever
$c->response_class is, which might not be Catalyst::Response).

Should Catalyst itself be handled in the same way you're suggesting
(create artificial superclasses)?  The way I'm doing the component
plugins is the same as how normal plugins are currently pulled into
Catalyst (unshift into @ISA, rather than create new superclass).

-- Brandon