[Catalyst] Caching problem?

[Brandon Black]

On 1/13/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Thu, Jan 12, 2006 at 03:30:12PM -0600, Brandon Black wrote:
> > On 1/12/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > > On Wed, Jan 11, 2006 at 10:27:14PM -0600, Brandon Black wrote:
> > > > 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.
> > >
> > > It's a little bit awkward, but it could easily be made to happen automagically
> > > (e.g. with -Request(NoCache SomethingElse) in the 'use Catalyst' line), it's
> > > just there hasn't been much call for it so I didn't worry too much.
> > >
> > > Alternatively, we could go with the "all plugins in one namespace" approach
> > > and have a 'plugin_for' classdata thing in each Plugin that says whether it
> > > should end up in the @ISA for the appclass, request class, response class etc.
> > >
> > > For 5.5 I concentrated on getting the hooks in there for nice stuff later;
> > > actually writing the sugar was left until we had some use cases to write it
> > > against. Now, apparently we have one - what does everyone think?
> > >
> > > > At least with the ugly namespace plugin, it layers with other plugins
> > > > like itself just fine.
> > >
> > > Right until one of them needs to overlay no_cache. namespace-stuffing plugins
> > > are *always* bad news. Try mixing multiple things out the Class::DBI::Plugin
> > > namespace if you want a good demonstration of why ...
> > >
> >
> > Hmmmm.  I kinda like the plugin_for approach, it seems the most
> > sensible from the users' perspective, as then there's no difference to
> > them in how they load/use a plugin based on how it was implemented
> > behind the scenes.
> >
> > Currently normal plugins are @ISA'd into the appclass automagically at
> > plugin load time.  Keep that as the default, but check for a
> > pluginclass->plugin_for to optionally @ISA it into something else
> > (request, response, etc) instead.  Then I could have put ->no_cache
> > directly in my plugin class, and used NEXT, the same way existing
> > appclass plugins override methods like ->finalize.
>
> Right, that's the lines I was thinking along - does anybody fancy doing up
> a patch for this? It's not likely to get to the top of my to-do list amazingly
> soon, I'm afraid.
>

I could take a stab at it.  I'm assuming the general idea should be an
optional new C::P::Base class which creates the plugin_for accessor
for those that want to inherit and use it, and then mod the plugin
loader code to look for it when loading plugins.

-- Brandon