Nested routes question

Trying to convert my app (and brain) to RESTful routes from the old
style. What is the accepted approach to nesting a resource within 2
other resources?

Example:

Models

Person has_many :scores
Contest has_many :scores
Score belongs_to :person, :contest

Routes

resources :people do
resources :scores
end

resources :competitions do
resources :scores
end

I want to be able to list scores by person, or by competition. Either
of the these two paths will request the :index action in the :scores
controller:

GET /people/person_id/scores
GET /contests/contest_id/scores

So what is the best way to structure scores/index to deliver the
appropriate list?

I could test for the presence of params[person_id] or
params[contest_id], then execute and render accordingly within
the :index action. But that seems somewhat inelegant. Is there a
better way? Should I have two separate actions within the :score
controller, and modify my route mapping somehow to request the
appropriate action?

bump … no answers?

I could test for the presence of params[person_id] or
params[contest_id], then execute and render accordingly within
the :index action. But that seems somewhat inelegant.

How about writing something generic to get the parent? You
can add this at the bottom of your ScoresController for example:

private

def get_parent
params.each do |name, value|
return $1.classify.constantize.find(value) if name =~ /(.+)_id$/
end
nil
end

Have fun,
Franz

DONT DEEPLY NEST ROUTES DOOOOOOOOOONT!!!

Ed wrote:

Trying to convert my app (and brain) to RESTful routes from the old
style. What is the accepted approach to nesting a resource within 2
other resources?

Well, REST only has to do with routing and external interface. It tells
you nothing about the implementation details of how to structure your
controllers, which seems to be your real question here.

Example:

Models

Person has_many :scores
Contest has_many :scores
Score belongs_to :person, :contest

Routes

resources :people do
resources :scores
end

resources :competitions do
resources :scores
end

I want to be able to list scores by person, or by competition. Either
of the these two paths will request the :index action in the :scores
controller:

GET /people/person_id/scores
GET /contests/contest_id/scores

So what is the best way to structure scores/index to deliver the
appropriate list?

I could test for the presence of params[person_id] or
params[contest_id], then execute and render accordingly within
the :index action. But that seems somewhat inelegant.

Does it? If you want to reuse the same controller action, it seems
entirely reasonable to test the data you’re getting passed.

Is there a
better way? Should I have two separate actions within the :score
controller, and modify my route mapping somehow to request the
appropriate action?

You could do that, certainly. I think I’d use the former solution,
though.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

What is the difference between persons and contests as far as scores
are concerned? Looks to be a polymorphic relationship based on the
context of your post. Person to Scores and Scores to Contest.

I agree with radhames, though in lower case. I’ve found that you need
only be concerned with one level of nesting at a time.

On Sep 6, 4:35 am, Ed [email protected] wrote:

Score belongs_to :person, :contest

I think that you should use HABTM :through, the rest should be easy

Bb Serviss wrote:

What is the difference between persons and contests as far as scores
are concerned? Looks to be a polymorphic relationship based on the
context of your post. Person to Scores and Scores to Contest.

That’s not my interpretation. It looks like a score belongs to a person
and a contest simultaneously.

I agree with radhames, though in lower case. I’ve found that you need
only be concerned with one level of nesting at a time.

That’s all that the OP was concerned with, I think.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs