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. I don't regard
that as a an option. Especially, since the Schema-classes are created by
the helper script.
If I use the method I describe, I can do this with inheritance and
keep my classes clean and available to applications that don't use
Catalyst or DBIx::Class.
(*) BTW, the behavior you described does work intentionally, for cases
when you need the objects in Catalyst to be different than with plain
DBIC. I think it's a bad idea to use this "feature" except in very
special cases -- of which "full_name" is not one.
full_name() was just a very simple example to illustrate the problem.
The real use case is a lot more complex and involves functionality that
has nothing to do with DBIx::Class.
Cheers,
Alex
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
