[Catalyst] Re: use for expand_modules
(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)
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: use for expand_modules
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL PSGI Catalyst - third development release
- Original Message - From: Tomas Doran bobtf...@bobtfish.net To: Pedro Melo m...@simplicidade.org Cc: The elegant MVC web framework catalyst@lists.scsys.co.uk Sent: Saturday, August 6, 2011 10:47 AM Subject: Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL PSGI Catalyst - third development release On 2 Mar 2011, at 15:08, Pedro Melo wrote: I've just tested my app with the this version. I've noticed a small difference with Catalyst::Test. The latest stable version include two headers, 'host' and 'https'. They are missing from this version. Is this a documented change that I missed or a bug? Could we possibly be talking about this method: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Test.pm;h=5c0cbe7cfd9ea22e2a20c1b14d10d7b69367a0ee;hb=psgi#l396 I have been trying to find this to rectify it, but I can't reproduce the issue (in the current stable release). Which function from Catalyst::Test are you using, and are the headers in the request or the response? Any chance you could show us a short example? Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
