This is another one in my series: I post this here in case I forget how I did it last time... :-)

I just had the following problem in my Catalyst app:
As a model I am using a class that has nothing to do with the Catalyst app itself. I want to instantiate objects of this class once per request, so I extend Catalyst::Model::Factory::PerRequest like this (my class needs its parameters to "new" in list form, not hashref): 

package MyApp::Model::ProblemSolver;
use Moose;
use namespace::autoclean;

extends 'Catalyst::Model::Factory::PerRequest';

__PACKAGE__->config(
  class => 'MyNonCatalyst::ProblemSolver',
);

# provide arguments as a list  instead of hash-ref
sub mangle_arguments {
  my ($self, $args) = @_;
  return %$args;
}

[download]

Now, objects of the MyNonCatalyst::ProblemSolver class need some parameters that go well in the app's config file, e.g. details for a database connection. It also needs parameters that will depend on input from the user of the site.
I found out that I can add this to the above model class (this is using the Moose way of overriding a parent's method and calling SUPER): 

override 'prepare_arguments' => sub {
  my ($self, $c) = @_; 
  my $config_params = super();
  my $passed_in_params = $c->stash->{problem_solver_args};
  my %merged_args = ( %$config_params, %$passed_in_params ); 
  return \%merged_args;
}; # prepare_arguments

[download]
This will merge the parameters from the config file and those that were passed in from the controller in such a way that the controller arguments override the config defaults. In my controller I can now do something like this: 

$c->stash->{problem_solver_args}{some_param} = $user_input1 if $user_i
+nput1;
$c->stash->{problem_solver_args}{some_other_param} = $user_input2;

my $problem_solver = $c->model('ProblemSolver');
my $result = $problem_solver->solve_problem();

[download]
in my my_app.yaml config file for the app I have: 
Model::ProblemSolver:
  args:
    database: a_database_of_solved_problems
    some_param: SOME_DEFAULT_VALUE

[download]
This means that the database name is always taken from the app's config file but 'some_param' will be taken from user input if there is any or the above default is used to instantiate an object of the model class.

Replies are listed 'Best First'.
Re: instantiate objects from non-Catalyst model classes with parameters
by ruoso (Curate) on Jan 29, 2011 at 10:29 UTC

    interesting you mention this. I have just wrote a model factory based on Catalyst::Component::InstancePerContext...

    package Leilao::Model::Negocio;
use Moose;
extends 'Catalyst::Model';
use namespace::autoclean;
use Module::Find;
use Module::Load;
use Sub::Name;
use Catalyst::Component::InstancePerContext;
use Moose::Meta::Class;

sub BUILD {
    my ($self) = @_;
    my @modules = findallmod 'Leilao::Negocio';
    foreach my $neg (@modules) {
        load $neg;
        (my $mod = $neg) =~ s/^Leilao::Negocio/Leilao::Model::Negocio/
+;
        my $sub = sub {
            my ($self, $c) = @_;
            return $neg->new
              ( #user => $c->user,
                schema => $c->model('DB')->schema );
        };

        my $class = Moose::Meta::Class->create( $mod, superclasses => 
+['Catalyst::Model']);
        $class->add_method(build_per_context_instance => $sub);
        Catalyst::Component::InstancePerContext->meta->apply($class);
    }
}

__PACKAGE__->meta->make_immutable;
1;

    [download]

    This model will use create adapted models for every class in the Leilao::Negocio namespace using Catalyst::Component::InstancePerContext and initializing the classes with arbitrary parameters.

    daniel
[reply]
[d/l]

Back to Meditations