[Catalyst] Model API compliance
Matt S Trout
dbix-class at trout.me.uk
Mon Sep 4 20:26:15 CEST 2006
Mark Blythe wrote:
> On 9/4/06, *Rodney Broom* <rbroom+catalyst at rbroom.com
> <mailto:rbroom+catalyst at rbroom.com>> wrote:
>
> I'm looking for a doc on what exactly a new model API should
> implement to be compliant with Catalyst as we're considering rolling
> our own for performance and other features. Currently we can use
> CDBI and DBIx, but we wouldn't want to re-implement every aspect of
> these APIs in order to work under Catalyst.
>
> My guess is that no such document yet exists, and that it would be a
> back-compat nightmare to state a limited set of what CDBI/DBIx
> features things like plugins are allowed to use.
> I don't believe Catalyst makes any assumptions about what a given model
> can do. As far as I can tell, the only thing it expects is that a model
> should be a sub-class of Catalyst::Model.
Even that's not a requirement. The only requirement is "is a perl class".
If you want to be instantiated as a per-app object ("instance" component type
rather than "class" in the initial debug stuff) you need to provide a
COMPONENT method (which you can get by subclassing Catalyst::Model but can
happily implement yourself if you prefer, too).
I'd be interested to hear your "performance and other reasons" on the DBIC
list though, I've never yet encountered a situation where dropping DBIC
entirely was required to solve performance issues.
--
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/ +
More information about the Catalyst
mailing list