Re: [Catalyst] Catalyst::Model::RabbitMQ
I'm using a combination of CatalystX::ComponentsFromConfig and Net::Stomp::Producer. The first (t0m's code, even if released by me) allows you to avoid writing essentially empty model classes (and to apply roles via configuration file). The second is the one that actually deals with messaging. As the name implies it's using STOMP, but there's actually rather little in the interface that depends on it. It works like this: - a send method takes a destination (queue name, whatever), a hashref of headers (including a 'type', that I imagine being similar to RabbitMQ's routing key), and a byte string for the message payload - if the message payload is a reference, it is passed through a serialiser - a transform_and_send method allows you to pass some internal representation, and having the logic to transform it into a message in a specialised class We've been using something very similar at $work for a coulpe of years now, and it seems to be simple and flexible enough. -- dakkar - mobilis in mobile ___ 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] Catalyst::Model::RabbitMQ
On Sat, Aug 18, 2012 at 9:36 PM, Gianni Ceccarelli dak...@thenautilus.netwrote: I'm using a combination of CatalystX::ComponentsFromConfig and Net::Stomp::Producer. The first (t0m's code, even if released by me) allows you to avoid writing essentially empty model classes (and to apply roles via configuration file). The second is the one that actually deals with messaging. As the name implies it's using STOMP, but there's actually rather little in the interface that depends on it. It works like this: - a send method takes a destination (queue name, whatever), a hashref of headers (including a 'type', that I imagine being similar to RabbitMQ's routing key), and a byte string for the message payload - if the message payload is a reference, it is passed through a serialiser - a transform_and_send method allows you to pass some internal representation, and having the logic to transform it into a message in a specialised class We've been using something very similar at $work for a coulpe of years now, and it seems to be simple and flexible enough. Hmm, sounds like something which is definitely worth looking into, thanks! Slightly off topic here: Is there a sane way to send a message each time I do a DB insert/delete? From what I can see do I have to either: - Wriggle $c in to my Schema module and override the insert/delete methods - Create some wrapper method inside a Controller and call that, which in turn calls db insert/delete and then sends the message - Have the call next to my DB call in each function doing insert/delete All three feels bad in different ways, is there a fourth (and/or fifth) alternative I haven't thought of which makes this nicer? /Jon ___ 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] Catalyst::Model::RabbitMQ
On 18 August 2012 20:36, Gianni Ceccarelli dak...@thenautilus.net wrote: I'm using a combination of CatalystX::ComponentsFromConfig and Net::Stomp::Producer. The first (t0m's code, even if released by me) allows you to avoid writing essentially empty model classes (and to apply roles via configuration file). The second is the one that actually deals with messaging. As the name implies it's using STOMP, but there's actually rather little in the interface that depends on it. It works like this: - a send method takes a destination (queue name, whatever), a hashref of headers (including a 'type', that I imagine being similar to RabbitMQ's routing key), and a byte string for the message payload - if the message payload is a reference, it is passed through a serialiser - a transform_and_send method allows you to pass some internal representation, and having the logic to transform it into a message in a specialised class We've been using something very similar at $work for a coulpe of years now, and it seems to be simple and flexible enough. -- dakkar - mobilis in mobile It's 'normal' not to create Catalyst specific models, but to create your model outside of Catalyst (so you can use it in things like cron jobs for example) in which case you just use a thin adaptor class. See Catalyst::Model::Adaptor If you do it that way you don't need to publish a cpan module at all. - icydee ___ 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] Catalyst::Model::RabbitMQ
On Sat, Aug 18, 2012 at 10:43 PM, Ian Docherty catal...@iandocherty.comwrote: It's 'normal' not to create Catalyst specific models, but to create your model outside of Catalyst (so you can use it in things like cron jobs for example) in which case you just use a thin adaptor class. See Catalyst::Model::Adaptor If you do it that way you don't need to publish a cpan module at all. - icydee Was that for me or Gianni? I wasn't aware of Catalyst::Model::Adaptor, seems like a useful module. What is the general take on modules such as Catalyst::Model::WebService::Solr if it's 'normal' to use C::M::Adaptor? Isn't that pretty much the same as I was suggesting for RabbitMQ? Is it thought of as depricated? /Jon ___ 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/
