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 <[EMAIL PROTECTED]> wrote:
--- Jamie Neil <[EMAIL PROTECTED]> 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: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
