I have to admit I’m still wrapping my brain around not only MVS, but
RESTful designs, so I’m sorry if this is a newbie question.
I have these models:
raid
has_many :raid_drops
has_many :members, :through => :attendance
has_many :pickups
attendance
belongs_to :member
belongs_to :raid
member
has_many :attendances
has_many :raids, :through => :attendances
has_many :raid_drops
has_many :bank_activities
raid_drop
belongs_to :raid
belongs_to :member
belongs_to :pickup
pickup
belongs_to :raid
Now, my first instinct told me I should have a path like these to get
to a “raid_drop”:
/members/1234/raid_drops/92392
/raids/1/raid_drops/92392
Each will limit the search context to that specific member or raid,
but I don’t actually know how to do this.
The larger problem is, I want one page (/raids/123123, the “show”
action) to have a way to add more members, pickups, or drops from that
page. I have forms working which will do some of this – I can add
pickups and drops and so on, but I have the post from these forms send
to the pickup controller, and that redirects back to the view for the
raid. This is not perfect, and if I mix AJAX in, it becomes even less
so.
Any advice?
The associations look a bit tricky, eg. there is a relationship
between member and raid, and member and raid_drops, and also member
and raid_drops directly. I can only assume you have a reason for this
slightly circular arrangement.
I have a few forms that handle more than one association at a time,
and I actually find it easier using AJAX, because this can be managed
in a way that allows a more REST approach. It is going to depend a
bit on how you want the functionality, but the main parent seems to be
the member. In which case, adding new members is likely to involve a
full view update. adding pickup and drops could be done by using an
ajax call. just make sure you have the correct parent id being
included. (This can be either through hidden fields, or more often
within the path in the remote links/form definitions).
For example, If you have a controller for pickups then you can have an
index, update, (new), create, destroy and use resources routes. The
simplest way to view this is to have an index partial in the views
folder for the controller for that model or association. And then do
the render update for that area, using the index partial for that
model to replace that div or table etc. Remember to use the full
path name for the partial, so that it picks it up from the right view
folder.
In your case, because you have a number of interdependencies, each
area being updated, it may involve updating other areas of the view
too, but that can be done from within the render blocks by including
whichever index partials you need.
Don’t know if any of that helps, but it is the approach I take and it
generally works quite well. Once you have got the partials built, it
also tends to be fairly easy to re-use them in various different
views.
Tonypm
I ended up doing something like this in the controller:
def index
respond_to do |format|
format.html { # index.html.erb
index_load
}
format.js {
field = params[:field] || “item_name”
case field
when “item_name”
conditions = [‘item_name ILIKE ?’, “%#{params[:search]}%”]
@field = :item_name
when “disposition”
conditions = [‘disposition ILIKE ?’, “#{params[:search]}%”]
@field = :disposition
end
@items = RaidDrop.find(:all, :conditions => conditions)
}
format.xml {
index_load
render :xml => @raid_drops
}
end
end
…
protected
def raid_load
if !params[:raid_id].blank?
@raid = Raid.find(params[:raid_id])
end
end
def index_load
raid_load
if @raid
@raid_drops = @raid.raid_drops.sort
else
@raid_drops = RaidDrop.find(:all).sort
end
end
This allows me to access a raid_drop and have a form where I can fill
in the raid_id, or have it accessed with a pre-filled-in one (that is,
the paths are /raid_drop/new or /raid/1234/raid_drop/new)
I guess this is a “ploymorphic” controller. Works well so far 
–Michael