[Catalyst] Caching problem?

[Matt S Trout]

On Wed, Jan 11, 2006 at 10:27:14PM -0600, Brandon Black wrote:
> On 1/11/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> > 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.

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 ...

-- 
     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/ +