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

  • Tomas Doran at Aug 8, 2011 at 8:51 pm
    This is brilliant, and exactly what I was looking for.

    Thank you _so much_ for taking the time to write all of this up.

    On 8 Aug 2011, at 10:13, Gianni Ceccarelli wrote:

    - 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?
    Yes, indeed!

    I have built a few systems like this, except I've always used hooking
    after setup_components to read config and setup the components I have
    generated via MMC->create, embedding the logic to do the scaffolding
    into MyApp.

    Using expand_modules in the way you have to allow components to plug
    their controllers is a great hook to use. :_)
    Questions:

    - am I insane? :)
    No, not at all.

    You have a fairly scary use-case, but I think what you've done is
    perfectly reasonable.
    - is there a better / cleaner / more future-proof way of getting the
    same result?
    At a word, no. There are other techniques you could be using to get
    the same results, but they're likely to have the same sort of issues
    (i.e. we'll have to think hard about back-compat).

    I was more doing a survey to find out how people are using it in real
    life, as the current tests for the feature are woefully inadequate for
    testing anything other than the most trivial of use-cases.

    We can now write some tests for a more advanced use-case like yours in
    the Catalyst test suite, and then verify that everything you're doing
    is still possible / working when we shift the internals around (or at
    worst, that if we need to break something, we can explicitly document
    it, and how to get around it in the new version)..
    - will the "much better solution" that t0m hinted at still allow me
    this kind of contortions?
    Yes.

    In fact it should make doing them significantly easier and more
    flexible, with less hacks involved.

    The idea is (and there is a very active branch working on) porting the
    component discovery and loading to Bread::Board, allowing you much
    more flexibility in how things are wired up.

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
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