FAQ
(re-sent, since apparently the mailing list didn't like my previous
attempt)

Hello.

I am using expand_modules at work. It may not be the best solution to
my problem, but it seemed appropriate. Let's see if I can describe
what I'm doing.

I have a thing that just happens to be a Catalyst application, using
Catalyst::Engine::Stomp to respond to ActiveMQ messages instead of
HTTP requests. Since the actual logic of the application does not
depend on the fact that we're using Catalyst as a module loader and
dispatcher, I have written a sort of "insulation layer" between
Catalyst and the actual business logic.

The "insulated" consumer modules look like this:

package MyApp::Consume::Something;
use Moose;
extends 'MyFramework::Base::Consume';

sub routes {
return {
a_queue_name => {
a_message_type => \&a_method_to_handle_it,
another_message_type => \&you_get_the_idea,
},
a_different_queue => {
and_so => \&on_and_on,
},
}
}

# here go the actual subs / methods

The MyFramework::Base::Consume class is a Catalyst::Component (well,
better said, ->can('COMPONENT')), and implements a expand_modules
method that does more or less this:

- collect the queues this module wants to listen on
- create (via Moose::Meta::Class->create, and only if it's not already
there) a Catalyst Controller per queue, under the appropriate
namespace (the controller inherits from
Catalyst::Controller::MessageDriven, part of the
Catalyst::Engine::Stomp distribution)
- add a "after 'register_actions'" modifier on the controller to
create the actions that will dispatch the message to the appropriate
method as required

Pseudo-code:

sub expand_modules {
my ($class) = @_;
my @ret = ();
for my $queue (keys %{$class->routes}) {
my $controller_name = the_name_for($queue);
if (not is_controller_there($controller_name)) {
create_controller($controller_name,$queue);
}
for my $message_type (keys %{$class->routes->{$queue}}) {
add_after_register_actions(
$controller_name,
$message_type,
$class->routes->{$queue}{$message_type}
);
}
push @ret, $controller_name;
}
return @ret;
}

Answers to some probable questions:

- Can't your Consume modules be Controllers, and then you do
$something to the Dispatcher?

Maybe, but Catalyst::Engine::Stomp /
Catalyst::Controller::MessageDriven do enough strange things to the
dispatch, and I prefer not to rewrite them

- Do you really need to insulate your modules so much from Catalyst?

There is talk to use some other system to handle ActiveMQ in the
future, and I don't want to have to touch my code more than strictly
necessary

- How the &%$%$^# did you think this was a good idea?

Well, it *is* documented :) And it seems to be the obvious hook:
when loaded, my component creates more components?

Questions:

- am I insane? :)

- is there a better / cleaner / more future-proof way of getting the
same result?

- will the "much better solution" that t0m hinted at still allow me
this kind of contortions?

Thanks :)

--
Dakkar - <Mobilis in mobile>
GPG public key fingerprint = A071 E618 DD2C 5901 9574
6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

"Why's it called Ming?" said the Archchancellor, on cue.
The Bursar tapped the pot. It went *ming*.
-- Discworld archeology revealed
(Terry Pratchett, Moving Pictures)

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 2 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedAug 8, '11 at 9:13a
activeAug 8, '11 at 8:51p
posts2
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Gianni Ceccarelli: 1 post Tomas Doran: 1 post

People

Translate

site design / logo © 2022 Grokbase