[Dbix-class] class layout [was "Alias" schema option]

[Brandon Black]

On 7/24/06, Richard Jolly <richardjolly at mac.com> wrote:
> On 5 Apr 2006, at 16:39, Brandon Black wrote:
>
> [snip]
>
> > This also touches on (to some degree) the whole issue of best
> > practices for namespace management (class names) of the various
> > classes related to a single table (the ResultSource, the ResultSet,
> > and the Result classes), ResultSetManager and the related issues of
> > "default" resultset_class's (::_resultset? ::ResultSet?
> > MySchema::ResultSet::Foo? etc) and the load_classes M::F thing (in
> > that it would be nice if ->load_classes() would pick up
> > resultset/result classes that fit the default naming convention and
> > stuff them in the right place).
>
> What is the current best practice for package layout of user-written
> code?
>
> Currently we have files like:
>
> Project/Schema/Foo.pm            # table definition
> Project/Schema/ResultSet/Foo.pm  # resultset additions
> Project/Foo.pm                   # returned object additions
>
> Since Project::Foo objects are returned from
> $schema->resultset('Foo')->search, we defined additional methods needed
> in that package. But should they be there, or defined in
> Project::Schema::Foo?

I don't think there's anything wrong with what you're doing now.

I'm working on a feature for 0.08 (which hasn't been discussed or
approved by general consensus yet, so it might just die where its at,
or change significantly, ymmv), which adds a method "load_namespaces"
to Schema.pm.  There's a branch for it at
branches/DBIx-Class/load_namespaces.  These are the docs for it atm
(notice that I didn't add a facility for custom row objects yet, but
it would follow the same scheme as what you see here for sources and
resultsets).

--------------------------------------------------------------------------

=head2 load_namespaces

=over 4

=item Arguments: %options?

=back

This is an alternative to L</load_classes> above which assumes an alternative
layout for automatic class loading.  It assumes that all ResultSource classes
to be loaded are underneath a sub- namespace of the schema called
"ResultSource", and any corresponding ResultSet classes to be underneath a
sub-namespace of the schema called "ResultSet".

You can change the namespaces checked for ResultSources and ResultSets via
the C<resultsource_namespace> and C<resultset_namespace> options, respectively.

Any source which does not have an explicitly-defined corresponding ResultSet
will have one created in the appropriate namespace for it, based on
L<DBIx::Class::ResultSet>.  If you wish to change this default ResultSet
base class, you can do so via the C<default_resultset_base> option.  (Your
custom default should, of course, be based on L<DBIx::Class::ResultSet>
itself).

This method requires L<Module::Find> to be installed on the system.

Example:

  My::Schema->load_namespaces;
  # loads My::Schema::ResultSource::CD, My::Schema::ResultSource::Artist,
  #    My::Schema::ResultSet::CD, etc...

  My::Schema->load_namespaces(
    resultsource_namespace => 'My::Schema::RSources',
    resultset_namespace => 'My::Schema::RSets',
    default_resultset_base => 'My::Schema::RSetBase',
  );
  # loads My::Schema::RSources::CD, My::Schema::RSources::Artist,
  #    My::Schema::RSets::CD, and if no such class exists on disk,
  #    creates My::Schema::RSets::Artist in memory based on the
  #    class My::Schema::RSetBase