[Catalyst] Catalyst::Model::DBIC::Schema and ACCEPT_CONTEXT -- current user in model

[Kieren Diment]

On 14/05/2010, at 7:37 AM, Bill Moseley wrote:

> I've managed to keep context related items  (e.g. current user) out of my
> DBIC model up until now.  Now finding it would be very helpful to be able to
> call a method on a row object and have access to the current user.
> 
> So, I'm trying to hunt down an example of how to make a current user
> available to row objects.  Seems this has come up many times but not having
> much Google luck.
> 
> Anyone have a link or an example?
> 
> Thanks,
> 
> -- 
> Bill Moseley
> moseley at hank.org
> _______________________________________________


From the book:

=head2 Catalyst::Model::Factory and Catalyst::Model::Factory::PerRequest

Thanks to Johnathan Rockway for assistance.

We've used Catalyst::Model::Adaptor elsewhere in this book to set up a plain
class as a Catalyst model at application startup time.  This helps us to write
Models that will work equally well outside of Catalyst as inside Catalyst. If
you need more flexbility than this you should use
Catalyst::Model::Factory::PerRequest to instantiate your class once per
Catalyst request, or Catalyst::Model::Factory if you need a new object every
time you call a particular C<<$c->model>>.  Setup for either is the same as
Catalyst::Model::Factory.

Here's a simple Class that uses Catalyst::Model::Factory:

 package MyApp::Model::Something;
 use strict;
 use warnings;
 use parent 'Catalyst::Model::Adaptor';

 __PACKAGE__->config(
     class => 'Some::Plain::Class',
     args => { arg =>  $self->arg},
 );

 1;

=begin comment

JAR - It doesn't look like it uses Catalyst::Model::Factory.  Is there a missing
use line?

=end comment

Say we needed access to Catalyt's C<path_to> method in our Model.  We could
easily set this up within a Catalyst::Model::Adaptor model with the following
inside our MyApp::Model::FromAdaptor class:

 use Moose;
 use namespace::autoclean;
 sub ACCEPT_CONTEXT {
     my ($self, $c ) = @_;
     my $new = $self->meta->clone_object($self, arg => $c->path_to(''));
     return $new;
 }

However, if we needed information from the current Catalyst request object for
our model to work, then we'd want to use C<use parent
'Catalyst::Model::Factory' instead, and our ACCEPT_CONTEXT might look like
this:

=begin comment

JAR - Where would we C<use parent qw(Catalyst::Model::Factory) instead?

What is ACCEPT_CONTEXT?  I don't remember seeing that before.

=end comment

=begin comment

DWP - You've missed the closing > in the last para.

=end comment

 use Moose;
 use namespace::autoclean;
 sub ACCEPT_CONTEXT {
     my ($self, $c ) = @_;
     my $new = $self->meta->clone_object($self, arg => $c->req->path);
     return $new;
 }

=begin comment

JAR - Is this example (above) still giving us access to Catalyst's C<path_to>
method?  Or would we not need that?  I'm a bit confused.

=end comment

This is because models inheriting from Catalyst::Model::Factory are
instantiated at run time, and so don't have access to the current request path.

Finally if our model depended on something to do with the current application
state, we'd want to C<use parent 'Catalyst:Model::Factory::PerRequest'> and our
ACCEPT_CONTEXT subroutine might be as follows:

 use Moose;
 use namespace::autoclean;
 sub ACCEPT_CONTEXT {
     my ($self, $c ) = @_;
     my $new = $self->meta->clone_object($self, arg => $c->stash->{something});
     return $new;
 }