Josh P. wrote:
How should you map resources that are join models like Memberships?
Lets say have you have Members and Groups that are joined through
map.resources :members do |members|
members.resources :groups do |groups|
This doesn’t seem right.
It would be nice to access all members, groups, and memberships at
/members, /groups, and /memberships. /members/1/memberships should list
Member #1’s memberships. /groups/1/memberships should list Group #1’s
I think there isn’t a great way to handle that right now. I hope that
ActiveResource associations will help sort it out soon. You can
certainly create lots of routes and actions to do what you want, but it
will be generate a lot of ways to do the same thing and some non-DRY
map.resources :members do |member|
member.resources :memberships, :groups
map.resources :groups do |group|
group.resources :memberships, :members
map.resources :memberships do |membership|
membership.resources :members, :groups
That’s nice and simple, but now you have a situation where an action
must deal with three kinds of URLs, one for each kind of resource
mapping listed above. For instance, a member might be shown using the
Maybe not a big deal for #show, but what about the #new action? Does it
make sense to allow new for all three paths, or just one?
The big advantage of nested resources is that the parent resource
provides a context for the child. I’m using this successfully with
/articles/5/comments/7 type mappings. It simplifies things by making the
context for comments explicit. But I’d never want to say
/comments/7/articles to find a comment’s article.
If you ignored the member (as in member/collection/new route types)
actions for the child resources I think the multiple mappings could make
sense. But I’d stay away from turning your actions into case-statement
soup if it’s not really necessary.