[Catalyst] Caching problem?

[Matt S Trout]

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.

-- 
     Matt S Trout       Offering custom development, consultancy and support
  Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +