Hello all,
I’m about to start working on a part of my application that interfaces
with an external system using HTTP (old school, not webservices).
Anyway, several of my controllers will need to access this
functionality, but there are some places where the functionality doesn’t
fit perfectly with my design. I was thinking about putting most of the
interaction with the external site in its own controller and then
calling that from controllers in my application as needed. Of course,
such a controller wouldn’t be associated with a model. I’m not sure what
effect this will have.
How would you handle it?
Ready for the edge of your seat? Check out tonight’s top picks on Yahoo!
TV.
I’d put it into a class under lib/ and not into a controller;
controllers shall be thin and glue the view and the model. it depends
how you “see” your external resource; you can look at it like a model.
a bit more important could be the fact that external access to the
resource will lock-up your users request and bind one of your mongrel
(or rails instances) to that request. you can use backgroundrb (http://
backgroundrb.rubyforge.org/) for such cases and communicate
asynchronously with your external system.
There’s nothing wrong with controllers that aren’t directly related to a
model. If there are methods multiple controllers will use then I would
think the best place to put them is in the application controller.
Anyway, it’s a good idea to plan ahead, I think you’re on the right
track.
Hi Will,
I would hide the external system behind a Model. I view Controllers as
those things that manage the interactions between the ‘things’ in an
application. An external system, as it appears, is another ‘thing’ in
your
application.
This gives you the ability to use this Model in other controllers, or
other
applications should the need arise.
However, I’m sure you’ll get plenty of options from this list on which
to
choose a solution that fits your needs.
Cheers,
Mel R.