# Multi-tasking with RESTful controllers? **URL:** \ **Category:** rubyonrails-talk\ **Created:** [November 26, 2007, 7:57pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842 "2007-11-26T19:57:24Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![John\_Wells](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@John\_Wells](https://discuss.rubyonrails.org/u/John_Wells)\ **Post date:** [November 26, 2007, 7:57pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/1 "2007-11-26T19:57:24Z")
Guys, I'm working to get my head around REST. Reading the chapter in AWDROR is not helping unfortunately, but I think it may be a result of either an error in my copy of the book, or my understanding in general. REST in Rails for simple examples is easy to follow, but it's where associations come into the mix that I get a bit confused. Take the example in the AWDROR book. You have ArticlesController and CommentsController, and the appropriate nested resource mapping to make comments available via articles urls...so that you can do: /articles/1/comments and get a list of comments for the article with id 1. So far, so good. Now, extend this example hypothetically and say that I, for whatever reason, want to get all comments, irregardless of article. One would expect that, if #index is used for all listings of comments, then I'd have to write CommentsController#index as: def index   if params[:article\_id]     @comments = Article.find(params[:article\_id]).comments   else     @comments = Comment.find(:all)   end   respond\_to do |format|     format.html # index.rhtml     format.xml { render :xml =\> @articles.to\_xml }   end end This would allow the method to be used in two contexts...one where I'm after /articles/1/comments and one where I'm seeking just /comments Now, this design could get pretty nasty, I'd presume, because let's say I have other resources in my application that could also have comments. I'm suddenly forced to walk through the parameters for each method that could be called in this way and change the behavior of the resource accordingly. Here's where I think an error in the book is confusing me. Of course, it may not be an error at all. In the table on page 418, it lists actions that are called in response to various url mappings. The first listed in CommentsController says that Actions in CommentsController GET /articles/1/comments index               comments\_url(:article\_id =\> 1) This says that /articles/1/comments will call #index in the CommentsController, but if you'll note in the actual implementation of the CommentsController, there is no index defined!?! Which leads me to believe that this is wrong, and that #index will only ever be called when accessed directly via a GET to /comments So, two questions: 1. Is this actually incorrect on the part of the book? Is #index unnecessary when called in the context of a nested resource? 2. How does one manage a resource controller implemention of a resource that might be shared amongst different parent resources (i.e., I have three resources: Articles, BlogEntries, and ProductListings, all that have a has\_many :comments? Thanks for any help you can provide in cleaning up these mental cobwebs. John ---
**Author:** ![bphogan](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/bphogan/32/4186_2.png) [@bphogan](https://discuss.rubyonrails.org/u/bphogan)\ **Post date:** [November 26, 2007, 8:09pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/2 "2007-11-26T20:09:12Z")
That’s confusing, isn’t it? Its kinda up to you how you want it to work. Does it make sense to get a comment outside of the article scope? To me, it does not, so I wouldn’t even worry about that case. In fact, I’d make sure that there was no route that could even pull that URL up. Other cases, like /users/1/groups or /groups would make sense. In that case, you would definitely need to code for both. The thing to remember is that it’s about resources and URLs. What does your application require you to do? There’s no “right way” or “wrong way” for this particular case. ---
**Author:** ![John\_Wells](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@John\_Wells](https://discuss.rubyonrails.org/u/John_Wells)\ **Post date:** [November 26, 2007, 8:32pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/3 "2007-11-26T20:32:00Z")
> Its kinda up to you how you want it to work. Does it make sense to get a comment outside of the article scope? To me, it does not, so I wouldn't even worry about that case. In fact, I'd make sure that there was no route that could even pull that URL up. Yeah, bad example, but it's in a book just about everyone on this list has. So assume it \*does\* make sense to use comments outside of the context of Articles. > Other cases, like /users/1/groups or /groups would make sense. In that \> case, you would definitely need to code for both. > The thing to remember is that it's about resources and URLs. What does your application require you to do? There's no "right way" or "wrong way" for this particular case. So in the case of my example of Articles, BlogEntries, and ProductListings sharing comments, I'd have to do: def index   if params[:article\_id]     @comments = Article.find(params[:article\_id]).comments   elseif params[:blog\_entry\_id]     @comments = BlogEntry.find(params[:blog\_entry\_id]).comments   elseif params[:product\_listing\_id]     @comments = ProductListing.find(params[:product\_listing\_id]).comments   end   respond\_to do |format|     format.html # index.rhtml     format.xml { render :xml =\> @comments.to\_xml }   end end And the above assumes that CommentsController#index will indeed be called in response to /articles/1/comments, which the book seems to contradict itself on. For example, another confusing passage: "We'll create a CommentsController to manage the comments resource. We'll give it the same actions as the scaffold-generated articles controller, except we'll omit index and show, because comments are displayed only from an article's show action." (p 419) Thanks for your continued help. John ---
**Author:** ![bphogan](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/bphogan/32/4186_2.png) [@bphogan](https://discuss.rubyonrails.org/u/bphogan)\ **Post date:** [November 26, 2007, 8:49pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/4 "2007-11-26T20:49:19Z")
You’re on the right track. Keep going. Go with what your gut tells you with this stuff. Does it make sense? Absolutely it does. You’re polymorphically showing the comments for an article, a blog\_entry, etc. What you pass in the URL will determine what record it looks up. The way you’re doing it is nice and clean too because you access it via the scoped entity as opposed to doing comment.find\_by\_id. You’ll need logic similar to this for doing a show, and maybe even a new / create… Probably not for an edit, but then again, maybe. I suggest a before\_filter for that to reduce code duplication. ---
**Author:** ![John\_Wells](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@John\_Wells](https://discuss.rubyonrails.org/u/John_Wells)\ **Post date:** [November 26, 2007, 9:17pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/5 "2007-11-26T21:17:53Z")
So you're saying the CommentsController#index would indeed be called in response to /articles/1/comments? If so, then why do they specifically not implement this in the book example? Thanks, John ---
**Author:** ![bphogan](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/bphogan/32/4186_2.png) [@bphogan](https://discuss.rubyonrails.org/u/bphogan)\ **Post date:** [November 26, 2007, 9:27pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/6 "2007-11-26T21:27:44Z")
I don’t know what the book is suggesting you do. The index action refers to the return of a collection. If you have a nested route, /articles/1/comments would look for comments#index. ---
**Author:** ![Nicholas\_Henry](https://avatars.discourse-cdn.com/v4/letter/n/919ad9/32.png) [@Nicholas\_Henry](https://discuss.rubyonrails.org/u/Nicholas_Henry)\ **Post date:** [November 27, 2007, 1:06pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/7 "2007-11-27T13:06:08Z")
Brian, the issue with polymorphic resources has been experienced by others (I have not had to deal with this yet). If you are just starting out in RESTful design, then I'm not sure if this will be of help, but since you are asking the right questions it might be. James Golick has developed a plugin called ResourceController. Part of this responsibility is to solve the issue you raised. See the section "Polymorphic Resources". [http://jamesgolick.com/2007/10/19/introducing-resource\_controller-focus-on-what-makes-your-controller-special](http://jamesgolick.com/2007/10/19/introducing-resource_controller-focus-on-what-makes-your-controller-special) HTH, Nicholas ---
**Author:** ![bphogan](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/bphogan/32/4186_2.png) [@bphogan](https://discuss.rubyonrails.org/u/bphogan)\ **Post date:** [November 27, 2007, 2:12pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/8 "2007-11-27T14:12:38Z")
@Nicholas: I think you meant to direct this to the OP. ---
**Author:** ![Nicholas\_Henry](https://avatars.discourse-cdn.com/v4/letter/n/919ad9/32.png) [@Nicholas\_Henry](https://discuss.rubyonrails.org/u/Nicholas_Henry)\ **Post date:** [November 27, 2007, 2:20pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/9 "2007-11-27T14:20:30Z")
Quite right, Brian, sorry about that - yes my post was directed to John. ---
**Author:** ![John\_Wells](https://avatars.discourse-cdn.com/v4/letter/j/35a633/32.png) [@John\_Wells](https://discuss.rubyonrails.org/u/John_Wells)\ **Post date:** [November 27, 2007, 4:23pm UTC](https://discuss.rubyonrails.org/t/multi-tasking-with-restful-controllers/20842/10 "2007-11-27T16:23:55Z")
Very interesting...thanks Nicholas!