[Catalyst] Creating Good Adaptor or Bridge Models (WAS: Creating a thin Model)

[Zbigniew Lukasiak]

Some time ago I had this idea that the declarations we put into
MySite::Model::DBIC are entirely superfluous and that it would be much
simpler if we just needed to declare in the config file that the model
uses the MySite::Schema and have it generated automatically.  Matt
agreed and asked me to write tests for that feature - but I did not
know what should go into these tests.

So the idea is to be able to declare in the config file:

Model::ModelName :
   instantiate : MySite::Schema

and then use $c->model(ModelName) without actually creating the
MySite::Model::ModelName package anywhere.

So what are the tests that would go here?  I can think only about two:

- that $c->model(ModelName) is a Catalyst::Model
- that the config values are correctly used

Is there anything more?  This would automate what you put in the
first, simpler method of model building.

--
Zbyszek




On 5/22/07, John Napiorkowski <jjn1056 at yahoo.com> wrote:
> --- Jamie Neil <jamie at versado.net> wrote:
>
> > Matt S Trout wrote:
> > > If you get stuck, could you start a fresh thread,
> > please? I think this one
> > > has officially got confused now :)
> >
> > Ok. Just for the record though, this seems to be
> > working fine so far:
> >
> >
> > package MySite::Model::Widget;
> >
> > use strict;
> > use warnings;
> > use base qw/Catalyst::Model/;
> > use MySite::Widget;
> >
> > __PACKAGE__->config(
> >      connect_info => [
> >          'dbi:Pg:mysite', 'username',
> >          'password', { AutoCommit => 1 },
> >      ],
> > );
> >
> > sub new {
> >      my ( $class, $c, $args ) = @_;
> >      return MySite::Widget->new(
> >          Catalyst::Utils::merge_hashes( $args,
> > $class->config ) );
> > }
> >
> > 1;
>
> [CUT]
>
> Hey,
>
> Maybe we could summarize the best practice lessons
> from this thread?  If so I'll be happy to put them on
> the wiki someplace suitable.
>
> So we are saying it's better to override new instead
> of COMPONENT and that it's okay to return your class
> directly in new and not have to create an accessor and
> then use AUTOLOAD to dispatch method calls?
>
> So when you just want to make the object available via
> $c->model(...)->method you can do (in the catalist
> model):
>
> sub new {
>   my ($class, $c, $args) = @_;
>
>   return ExternalModule->new(
>     Catalyst::Utils::merge_hashes( $args,
> $class->config )
>   );
> }
>
> But if you are adapting and/or altering the method
> calls it would be better to:
>
> __PACKAGE__->mk_accessors(qw/some_object/);
>
> sub new {
>   my ($class, $c, $args) = @_;
>   my $self = $class->NEXT::new($c, $args);
>
>   $self->some_object(Someobject->new(
>     Catalyst::Utils::merge_hashes( $args,
> $class->config )
>
>   return $self;
> }
>
> sub adapted_method
> {
>   my $result = shift->some_object->internal_method;
>   ## Do something to $result
>   return $result;
> }
>
> The reason I ask is because there have been several
> ways of doing this very basic type of thing floating
> around CPAN and I'm sure I'm not the only one
> confused.
>
> Maybe we could try to generate a concise list of cases
> and then try to work out a best practices example for
> each?  I'm sure that would be a good thing for a wiki
> entry or even as part of the POD docs.
>
> --john
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/