Re: [Catalyst] Creating a thin Model
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;
package MySite::Widget;
use warnings;
use strict;
use base qw/Class::Accessor/;
use MySite::Schema::DB;
use Carp;
__PACKAGE__-mk_accessors(qw/schema/);
sub new {
my $self = shift-next::method(@_);
croak -connect_info must be defined
unless $self-{connect_info};
# Clone and connect to schema
$self-{'schema'} =
MySite::Schema::DB-connect( @{ $self-{connect_info} } );
return $self;
}
sub find {
my ( $self, $id ) = @_;
return $self-{'schema'}-resultset('Widgets')-find($id);
}
...
package MySite::Controller::Widget;
...
# Get widget
my $widget = $c-model('Widget')-find($id);
$c-stash-{'widget'} = $widget;
...
--
Jamie Neil | [EMAIL PROTECTED] | 0870 454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
Christopher H. Laco wrote:
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
Sorry...that pseudo code was too vague:
sub COMPONENT {
my $self = shift-NEW::new(@_);
$self-{'noncatclass'} = NonCatClass-new
return $self
}
Then, delegate via autoload, or use real methods to forward request to
the instance of the real class...
I assume you mean:
my $self = shift-NEXT::new(@_);
in which case it fails with:
Can't call NEXT::new from MyApp::Model::Widget::COMPONENT
I noticed that a number of newer models on CPAN were using this
construction:
use base qw/ Catalyst::Model /;
sub new {
my $self = shift-next::method(@_);
my $class = ref($self);
my ( $c, $args ) = @_;
$self-{'.mymodel'} = ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $self-config )
);
return $self;
}
sub ACCEPT_CONTEXT {
return shift-{'.mymodel'};
}
or is this only recommended if you need to make the context available in
the external module?
--
Jamie Neil | [EMAIL PROTECTED] | 0870 454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
On Mon, May 21, 2007 at 11:06:44AM +0100, Jamie Neil wrote:
Christopher H. Laco wrote:
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
Sorry...that pseudo code was too vague:
sub COMPONENT {
my $self = shift-NEW::new(@_);
$self-{'noncatclass'} = NonCatClass-new
return $self
}
Then, delegate via autoload, or use real methods to forward request to
the instance of the real class...
I assume you mean:
my $self = shift-NEXT::new(@_);
in which case it fails with:
That should be in 'sub new', and next::method would be better.
Or you could just return the intance of your external class - there's no
requirement for the return of MyApp::Model::Foo-new to be a MyApp::Model::Foo
object and $c-model('Foo') will happily return your OtherClass::Blah object.
I noticed that a number of newer models on CPAN were using this
construction:
use base qw/ Catalyst::Model /;
sub new {
my $self = shift-next::method(@_);
my $class = ref($self);
my ( $c, $args ) = @_;
$self-{'.mymodel'} = ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $self-config )
);
return $self;
}
sub ACCEPT_CONTEXT {
return shift-{'.mymodel'};
}
or is this only recommended if you need to make the context available in
the external module?
No, that's just plain silly. Could I have a list of the models that do that
so I can track down the authors and slap them, please?
sub new {
my ($class, $c, $args) = @_;
return ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $class-config )
);
}
would be quite sufficient.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical DirectorWant a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
Matt S Trout wrote:
use base qw/ Catalyst::Model /;
sub new {
my $self = shift-next::method(@_);
my $class = ref($self);
my ( $c, $args ) = @_;
$self-{'.mymodel'} = ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $self-config )
);
return $self;
}
sub ACCEPT_CONTEXT {
return shift-{'.mymodel'};
}
or is this only recommended if you need to make the context available in
the external module?
No, that's just plain silly. Could I have a list of the models that do that
so I can track down the authors and slap them, please?
http://search.cpan.org/search?query=catalyst%3A%3Amodel+accept_context
brings up most of them, but there are a few more like Net::Amazon.
sub new {
my ($class, $c, $args) = @_;
return ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $class-config )
);
}
Thanks, I'll give that a try.
--
Jamie Neil | [EMAIL PROTECTED] | 0870 454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
On Mon, May 21, 2007 at 12:31:22PM +0100, Jamie Neil wrote:
http://search.cpan.org/search?query=catalyst%3A%3Amodel+accept_context
brings up most of them, but there are a few more like Net::Amazon.
Looks like they were all cargo-culted from J Shirley's YouTube model. o
I shall be explaining the appropriate techniques to him and then he can
chases everybody else down and get them to change theirs :)
sub new {
my ($class, $c, $args) = @_;
return ExternalModule-new(
Catalyst::Utils::merge_hashes( $args, $class-config )
);
}
Thanks, I'll give that a try.
If you get stuck, could you start a fresh thread, please? I think this one
has officially got confused now :)
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical DirectorWant a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
Christopher H. Laco wrote:
Jamie Neil wrote:
Can anyone tell me the best way of wrapping a non catalyst perl module
in a Catalyst Model?
I'm trying to setup the following stack:
MyApp::Controller::Widget
MyApp::Model::Widget
MyApp::Logic::Widget
MyApp::Schema::DB
where MyApp::Model::Widget is based on Catalyst::Model, contains the
configuration information for MyApp::Logic::Widget, and makes the
methods in MyApp::Logic::Widget available in MyApp::Controller::Widget
as $c-Model('Widget')-mymethod(...);
MyApp::Schema::DB is a DBIC Schema which I want MyApp::Logic::Widget to
use for storage, but not just passed through to the Model in the same
way that Catalyst::Model::DBIC::Schema does.
There is obviously more than one way to do this from looking at all the
other models on CPAN, but is there some kind of best practice? Should I
use AUTOLOAD, ACCEPT_CONTEXT, COMPONENT, override new or something else?
I did see a very promising thread on this issue a few months ago, but
this question
(http://lists.scsys.co.uk/pipermail/dbix-class/2007-January/003289.html)
was never really answered. I've been going round and round in circles on
this for a couple of weeks now, so some pointers (or even better example
code) would be most welcome.
You're right. It depends on a few things.
Does the module you're wrapping have a new? Is it statefull? stateless?
Is it self creating, or is it a factory that creates other things.
Those are all factors.
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
Sorry...that pseudo code was too vague:
sub COMPONENT {
my $self = shift-NEW::new(@_);
$self-{'noncatclass'} = NonCatClass-new
return $self
}
Then, delegate via autoload, or use real methods to forward request to
the instance of the real class...
-=Chris
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
Jamie Neil wrote:
Can anyone tell me the best way of wrapping a non catalyst perl module
in a Catalyst Model?
I'm trying to setup the following stack:
MyApp::Controller::Widget
MyApp::Model::Widget
MyApp::Logic::Widget
MyApp::Schema::DB
where MyApp::Model::Widget is based on Catalyst::Model, contains the
configuration information for MyApp::Logic::Widget, and makes the
methods in MyApp::Logic::Widget available in MyApp::Controller::Widget
as $c-Model('Widget')-mymethod(...);
MyApp::Schema::DB is a DBIC Schema which I want MyApp::Logic::Widget to
use for storage, but not just passed through to the Model in the same
way that Catalyst::Model::DBIC::Schema does.
There is obviously more than one way to do this from looking at all the
other models on CPAN, but is there some kind of best practice? Should I
use AUTOLOAD, ACCEPT_CONTEXT, COMPONENT, override new or something else?
I did see a very promising thread on this issue a few months ago, but
this question
(http://lists.scsys.co.uk/pipermail/dbix-class/2007-January/003289.html)
was never really answered. I've been going round and round in circles on
this for a couple of weeks now, so some pointers (or even better example
code) would be most welcome.
You're right. It depends on a few things.
Does the module you're wrapping have a new? Is it statefull? stateless?
Is it self creating, or is it a factory that creates other things.
Those are all factors.
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
--- Christopher H. Laco [EMAIL PROTECTED] wrote:
Christopher H. Laco wrote:
Jamie Neil wrote:
Can anyone tell me the best way of wrapping a non
catalyst perl module
in a Catalyst Model?
I'm trying to setup the following stack:
MyApp::Controller::Widget
MyApp::Model::Widget
MyApp::Logic::Widget
MyApp::Schema::DB
where MyApp::Model::Widget is based on
Catalyst::Model, contains the
configuration information for
MyApp::Logic::Widget, and makes the
methods in MyApp::Logic::Widget available in
MyApp::Controller::Widget
as $c-Model('Widget')-mymethod(...);
MyApp::Schema::DB is a DBIC Schema which I want
MyApp::Logic::Widget to
use for storage, but not just passed through to
the Model in the same
way that Catalyst::Model::DBIC::Schema does.
There is obviously more than one way to do this
from looking at all the
other models on CPAN, but is there some kind of
best practice? Should I
use AUTOLOAD, ACCEPT_CONTEXT, COMPONENT, override
new or something else?
I did see a very promising thread on this issue a
few months ago, but
this question
(http://lists.scsys.co.uk/pipermail/dbix-class/2007-January/003289.html)
was never really answered. I've been going round
and round in circles on
this for a couple of weeks now, so some pointers
(or even better example
code) would be most welcome.
You're right. It depends on a few things.
Does the module you're wrapping have a new? Is it
statefull? stateless?
Is it self creating, or is it a factory that
creates other things.
Those are all factors.
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
Sorry...that pseudo code was too vague:
sub COMPONENT {
my $self = shift-NEW::new(@_);
$self-{'noncatclass'} = NonCatClass-new
return $self
}
Then, delegate via autoload, or use real methods to
forward request to
the instance of the real class...
-=Chris
Any comments on why it's better to override
'COMPONENT' as opposed to 'new'? I could never really
figure out the advantages or disadvantages for either.
Of course if you are going to subclass a model that
might use 'ACCEPT_CONTEXT' then new is the only way to
go.
--john
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
List: Catalyst@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/
Re: [Catalyst] Creating a thin Model
John Napiorkowski wrote:
--- Christopher H. Laco [EMAIL PROTECTED] wrote:
Christopher H. Laco wrote:
Jamie Neil wrote:
Can anyone tell me the best way of wrapping a non
catalyst perl module
in a Catalyst Model?
I'm trying to setup the following stack:
MyApp::Controller::Widget
MyApp::Model::Widget
MyApp::Logic::Widget
MyApp::Schema::DB
where MyApp::Model::Widget is based on
Catalyst::Model, contains the
configuration information for
MyApp::Logic::Widget, and makes the
methods in MyApp::Logic::Widget available in
MyApp::Controller::Widget
as $c-Model('Widget')-mymethod(...);
MyApp::Schema::DB is a DBIC Schema which I want
MyApp::Logic::Widget to
use for storage, but not just passed through to
the Model in the same
way that Catalyst::Model::DBIC::Schema does.
There is obviously more than one way to do this
from looking at all the
other models on CPAN, but is there some kind of
best practice? Should I
use AUTOLOAD, ACCEPT_CONTEXT, COMPONENT, override
new or something else?
I did see a very promising thread on this issue a
few months ago, but
this question
(http://lists.scsys.co.uk/pipermail/dbix-class/2007-January/003289.html)
was never really answered. I've been going round
and round in circles on
this for a couple of weeks now, so some pointers
(or even better example
code) would be most welcome.
You're right. It depends on a few things.
Does the module you're wrapping have a new? Is it
statefull? stateless?
Is it self creating, or is it a factory that
creates other things.
Those are all factors.
Personally, I almost always do:
sub COMPONENT {
my $self = NEXT::new
diddle config...return $self
}
Sorry...that pseudo code was too vague:
sub COMPONENT {
my $self = shift-NEW::new(@_);
$self-{'noncatclass'} = NonCatClass-new
return $self
}
Then, delegate via autoload, or use real methods to
forward request to
the instance of the real class...
-=Chris
Any comments on why it's better to override
'COMPONENT' as opposed to 'new'? I could never really
figure out the advantages or disadvantages for either.
Of course if you are going to subclass a model that
might use 'ACCEPT_CONTEXT' then new is the only way to
go.
--john
I'm sure there are reason... I just don't know them. :-)
Maybe that COMPONENT receives $app, $config, before there's a model
instance...while new happens just a tad later for some config goodness...
ENOCLUE
-=Chris
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@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/
