[Catalyst] Caching problem?

[Brandon Black]

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.

-- Brandon