Re-using crontrollers with non-http requests

#1

Hi!

I am creating a application that does a lot of background processing.
For this I am using a queue (starling in my case…) and several pollers
that will get a message from the queue and execute some code
corresponding do it.

The code that these pollers process looks a lot like some code in
methods included in some of my rails application controllers. I wanted
to DRY this a little bit, so I tried to use the controllers method.

What I ended up doing is basically using an
ActionController::Integration::Session, exactly like in the console or
when doing tests.

I wanted to know if that was absolutely wrong or if it was ok. I guess
there are some consequences as well, but what are they?

Thanks a lot for your help!

#2

On Sun, Oct 12, 2008 at 12:01 AM, Julien Genestoux
removed_email_address@domain.invalid wrote:

The code that these pollers process looks a lot like some code in
methods included in some of my rails application controllers. I wanted
to DRY this a little bit, so I tried to use the controllers method.

I wanted to know if that was absolutely wrong or if it was ok. I guess
there are some consequences as well, but what are they?

I’ll let someone with more experience respond to that, but wouldn’t
it make sense (and be ultimately cleaner) to refactor those methods
out of the controller(s) into application.rb?

FWIW,

Hassan S. ------------------------ removed_email_address@domain.invalid

#3

Controllers are designed (in MVC patterns) to process requests and
deliver
responses. Rails-based controllers are designed for HTTP request/
response.
The answer is to make your own controller that answers your agents’
responses.

Take advantage of Ruby here - take common code OUT of the controllers
and
put it into modules. Include the modules into your controllers, then
make
your own listener class that also mixes those models in. Use a daemon to
keep that listener going. Railscasts.com has a nice screencast on
daemons.

How does that sound?

On Tue, Oct 14, 2008 at 3:50 PM, Julien Genestoux <

#4

Thanks Brian for this!

That sounds good! A lot of work, but good, thanks for this!

julien

Brian H. wrote:

Controllers are designed (in MVC patterns) to process requests and
deliver
responses. Rails-based controllers are designed for HTTP request/
response.
The answer is to make your own controller that answers your agents’
responses.

Take advantage of Ruby here - take common code OUT of the controllers
and
put it into modules. Include the modules into your controllers, then
make
your own listener class that also mixes those models in. Use a daemon to
keep that listener going. Railscasts.com has a nice screencast on
daemons.

How does that sound?

On Tue, Oct 14, 2008 at 3:50 PM, Julien Genestoux <

#5

Hassan S. wrote:

On Sun, Oct 12, 2008 at 12:01 AM, Julien Genestoux
removed_email_address@domain.invalid wrote:

The code that these pollers process looks a lot like some code in
methods included in some of my rails application controllers. I wanted
to DRY this a little bit, so I tried to use the controllers method.

I wanted to know if that was absolutely wrong or if it was ok. I guess
there are some consequences as well, but what are they?

I’ll let someone with more experience respond to that, but wouldn’t
it make sense (and be ultimately cleaner) to refactor those methods
out of the controller(s) into application.rb?

FWIW,

Hassan S. ------------------------ removed_email_address@domain.invalid

Thanks Hassan,

Hum, I am a little confused, but I don’t think so… Actually, I am
about to write implementations for AbstractResponse and AbstractRequests
so that I can call the controller’s methods with them!

Anyone else has tips/opinions about this?