More Nested Resources Questions...

Ok... quick example...

client has_many :locations vendor has_many :locations

so my resources is something like...

map.resources :clients, :has_many => :locations map.resources :vendors, :has_many => :locations map.resources :locations

Now, my new location view's form looks like this...

form_for( [ @client, @location ] ) do |f|

N.B.: I have a before_filter in my Location controller that sets @client = Client.find(params[:client_id])

the problem is, what if the new location is supposed to belong to a vendor? Do I need to have a separate resource for the two different types of resources? What's the best way to go about tackling this issue?

I swear once I get this all figured out I'm gonna write up a nice little write up for google to catch :slight_smile:

No clue?

It's scary how little information there is on RESTful development in Rails, yet it's supposed to be "the way" to program. :frowning:

I've been reading all night and I can't figure this one out. can anyone point me to a direction that might be able to help.

I apologize if this is un-necessary "spam" or "bumping"

I am going to assume that you're using a polymorphic association on location, something like:

class Location < ARec::Base   belongs_to :locatable, :polymorphic=>true end

class Vendor (or Client) < ARec::Base   has_many :locations, :as=>:locatable end

The polymorphic association gives you the clue. Instead of finding a @client or a @vendor, find a @locatable

locations_controller.rb ... def new   @locatable = params[:vendor_id] ? Vendor.find(params[:vendor_id]) : nil   @locatable ||= Client.find(params[:client_id]) if params[:client_id]   @location = @locatable.locations.build end ...

locations/new.html.erb form_for( [ @locatable, @location ] ) do |f| ... end

check out http://api.rubyonrails.org/classes/ActionController/Resources.html Disclaimer: I too am still learning RESTful routes, which is pretty involved.

But I think you need to nest the routes as each Client and vendor will have only one location.

like

map.resources :clients do |client|     client.resource :location end

map.resources :vendors do |vendor|     vendor.resource :location end

This should give you vendor and client routes like: vendors/3/location clients/5/location

Note that clients and vendors are plural and thus use map.resources (plural) and that location is singular and the receiver of the singular 'resource' message is a vendor object, not a map.

Good reading on the subject can be found in David A Black's "Rails Routing", which is a bit outdated, but gives you a good fundamental understanding of RESTful Routes. I think it is still well worth the 15 bucks as David has a wonderful gift of presenting complex material in a manner in which mere mortals can understand.

Duh, OK so clients and vendor have many locations (seems like they would have one)

map.resources :clients do |client|     client.resources :locations end

map.resources :vendors do |vendor|     vendor.resources :locations end

This should give you vendor and client routes like: vendors/3/location/2 clients/5/location/2

BUT... Maybe you learned the difference between singular and plural RESTful routes.

Teedub

Thanks Andy, I'll check that out.. that may be what I'm looking for...

Frank, I understand the concepts you're outining, my issues arise when I try to redirect after adding a location for example... do I go to show a client or do I go to show a vendor? And no, they can have many locations for example if my client is Walmart, they have many locations that I want to know of...

Where it breaks down for me is with the forms for and the redirects after a CRUD call, because I don't know how to tell the app to go to show the Client or the Vendor or whatever the location object belongs to. And passing @client, @location to the form_for works, but what about the vendor form? I'd have to have some ugly if statements in my view... and what if location is associated with 10 different models... i'm hoping Andy's advice helps.

The more I think about it, the form_for thing isn't really an issue.... since one would be coming from the Client's Views, and one would be coming from the Vendor's view...

Then based on the view it came from, ( IE is @vendor or @client set ) redirect back to the correct SHOW action in the correct controller...