Catalyst - components from other namespace

roman has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

is there a sane way how to make Catalyst application use controllers, views or models from other namespace?

Imagine MyApp, YourApp applications which want to use OurApp::Controller::Request, OurApp::View::Mason, OurApp::Model::Customer components.

I can easily load the components:

__PACKAGE__->config(
    setup_components => {
        search_extra => [qw(OurApp::Controller OurApp::Model OurApp::V
+iew)],
    }
);
[download]

But I would also like the loaded components to be reached via $c->view('Mason'), $c->model('Customer::Request'), $c->controller('Request') and let the Mason view be the default one.

Has anyone dealt with a similar situation? I appreciate any advice.

Comment on Catalyst - components from other namespace Download Code

Replies are listed 'Best First'.
Re: Catalyst - components from other namespace by stonecolddevin (Parson) on Mar 17, 2011 at 17:43 UTC
CatalystX::InjectComponent allows you to inject arbitrary classes into your app, but I have to ask what you're trying to achieve by this? If you want to use a, say, Moose class, as a model for instance, you can use Catalyst::Model::Adaptor. mtfnpy	[reply]
Re^2: Catalyst - components from other namespace by roman (Monk) on Mar 17, 2011 at 19:28 UTC
It seems that CatalystX::InjectComponent does what I need. I have two applications sharing quite a lot of codebase (they are actually two interfaces to one backend). They have many common actions, they use same DBIx::Class::Model, they both render their output via Mason with same configuration. Of course I could create OurApp::Controller::* and inherited it by MyApp::Controller::* and YourApp::Controller::*, but it just triples the number of files.	[reply]
Re^3: Catalyst - components from other namespace by stonecolddevin (Parson) on Mar 17, 2011 at 20:20 UTC
In that case I'd work on putting together an API layer over the backend and having the web apps just be layers on top of THAT that use those API calls as opposed to injecting this with that and such. It will give you a tremendously more flexible application structure. mtfnpy	[reply]