* On Mon, Feb 23 2009, Alexander Tamm wrote: >>> It looks a bit weird to me, but it seems to work. Should it work? >> >> You shouldn't do this (*), it is very confusing. Put functions like >> this in the row class, i.e. YourApp::Schema::Foo::User, so that all >> users of the schema have access to these methods. > > The reason I want to do this (or something similar) is that I don't > want all the database-specific cruft in the class I'm editing. I'm > trying to keep the classes clean and separate the storage from the > functionality. If I put the functionality in the Schema::*, I will > have about 400 lines of code that I need to replicate across eight or > more sites and the classes won't be usable without DBIx::Class or > Catalyst.
No, your current solution is the one that's not usable without Catalyst and DBIC. If you just want some random classes, you write them: package Class; use Moose; has 'some_row_object' => ( is => 'ro', does => 'Some::Interface', required => 1, ); # code goes here 1; I usually "wrap" the DBIC classes like this when I have operations that logically operate on a group of "unrelated" (in the DB) objects, or operate on two separate schemas. (What most people do in the controller I do in what I call "Backend" classes. It's the glue between the low-level DBIC stuff, and high-level operations.) If your classes depend on the structure of DBIC results, then the code needs to go in your schema classes. That is how everyone does it. (Your "full_name" example is just the sort of thing that you would keep inside DBIC.) Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$" _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/