[Catalyst] Catalyst::Model::Adaptor - because models shouldn't *do* anything

[John Napiorkowski]

--- Jonathan Rockway <jon at jrock.us> wrote:

> Hi all,
> 
> I've been noticing that more and more people seem to
> be writing Catalyst
> models that do things that other modules on CPAN
> don't.  This is not
> good.  Instead of writing a reusable module, people
> are tying their
> logic to Catalyst, which is bad for everyone.  When
> you tie your Model
> to Catalyst, you're stuck with Catalyst.  To test
> it, you have to mock
> Catalyst.  To use it outside of Catalyst, ... you
> can't.  It just makes
> everything painful, and for absolutely no reason.
> 
> Hopefully you see the problem.
> 
> What you should do instead is write a class that
> does your Model stuff
> without referring to Catalyst.  Once that's written
> and tested, you just
> need a few lines of code to glue your class to
> Catalyst.  Now your logic
> is available inside AND outside of Catalyst. 
> 
> If you are looking for something on CPAN that does
> this, look at
> DBIx::Class and Catalyst::Model::DBIC::Schema. 
> You'll notice that
> C::M::D::Schema doesn't do anything logic-related. 
> It's 100% glue to
> make using your DBIC schema from Catalyst easy.  All
> the important stuff
> works exactly the same without Catalyst.
> 
> To encourage people to design their models this way,
> I've released
> Catalyst-Model-Adaptor, which will do all the gluing
> for you:
> 
>
http://search.cpan.org/~jrockway/Catalyst-Model-Adaptor-0.01/lib/Catalyst/Model/Adaptor.pm
> 
> There are actually three variants, Adaptor, Factory,
> and
> Factory::PerRequest.  The Adaptor variant will
> create one instance of
> your class at application startup time, and will
> return that every time
> you call $c->model.  The Factory variant will create
> a fresh instance of
> your class every time you call $c->model (and you
> have an opportunity to
> pass data about the request to your model, although
> you should avoid
> this if possible).  Finally, the Factory::PerRequest
> variant will return
> a new instance of your class for each request.
> 
> If none of these patterns meet your needs, just
> write the Catalyst model
> part yourself.  These modules are only about 30
> lines of code combined,
> so nothing complicated is going on.  They just make
> it really easy to
> glue plain classes to Catalyst.
> 
> Anyway, I hope this makes it easier to write clean,
> reusable code for
> use with Catalyst.  Have fun!
> 
> Regards,
> Jonathan Rockway

One thing that I've done a lot with these kinds of
adapters is use AUTOLOAD or use Moose's built in
attribute delegation to make calling the adapted
classes methods easier.  Would you take a patch for
something like this and how might you envision it
working.  As a plugin, for example?

Thanks!
John

> 
> 
> 
> > _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo:
>
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 



       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC