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.
on 2007-06-27 17:48
on 2007-06-27 18:10
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.
on 2007-06-27 18:12
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.
on 2007-06-27 18:13
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.