[LRUG] Rails Question : Matching Share Nested Resources to Controllers
James Adam
james.adam at gmail.com
Mon Nov 5 05:32:07 PST 2007
On 11/5/07, Anthony Green <Anthony.Green at bbc.co.uk> wrote:
> What are peoples views on what is a sensible approach on what controller
> strategy you should employ for shared nested resources
>
> ie
>
> /books/
> /authors/id/books
> /publishers/id/books
It depends on whether or not you need to do different things when
creating, retrieving, updating or destroying books in those different
contexts.
For example, if a POST to authors/<id>/books should result in
significantly different behaviour to a POST to /publishers/<id>/books
(perhaps when you are posting to the author-nested collection you
might also put it in some queue for editors to deal with it), then you
would probably want to handle this in a separate method (and thus
likely a different controller) to the "vanilla" book creation. I'm
sure you can imagine analogous situations for showing or deleting
records.
There may also be specific actions that a publisher might take on a
book that authors should not be able to, and vice versa.
/publishers/123/books/999/publish, compared with
/authors/456/books/999/submit_to_editor, or something like that...
On the other hand, if you're just creating a Book record that may or
may not be associated with some kind of polymorphic "owner" (an author
or a publisher), with little other associated logic, I don't see any
reason to duplicate that all over the place.
It's also worth bearing in mind that there are ways to avoid
duplication that don't result in One Controller To Rule Them All. If
you can identify duplication in, say, the way that you locate the
specific book instance based on parameters, then extract that method
out - ApplicationController (or a common ActionController::Base
subclass) would work fine for this.
--
* J *
~
More information about the Chat
mailing list