Standard practices for RESTful remote (AJAXified) manipulation of nested resources?

In a nutshell:

I've got 2 RESTful resources and complex edit page for the parent
resource. I want to modify the nested resource from the parent
resource's edit page, and I want to use AJAX to do it. I'm having a
really hard time finding a clean way to organize the RJS and partials
artifacts.

More detail:

I'm writing a RESTful Rails app and I'm bumping into almost exactly
the same xhr context problem described at the very end of this post...

    http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/59998e003c538743

...and in this July, 2006 blog post from Bruce Williams...

    http://codefluency.com/2006/7/1/rails-views-getting-in-context

Question 1: Have there been any additions to core Rails that address
this context problem?

More than anything, I feel like this context issue has introduced a
lot of codebase uncleanliness. Uber-quick example:

I have a Foo resource with a nested Bar resource.

From a form in foos/show.rhtml, I want to update the nested Bar

resource via BarsController:update.

Great...so, I hit the update action in the BarsController. In my
respond_to, I do a switch on the appropriate context and then render a
context-specific RJS.

Question 2: Where should these context-specific RJS files live? Under
views/bars or views/foos?

I think the common approach would be for (say) update_context1.rjs to
live under views/bars. It really bugs me, though, that this file is
going to contain a div id for some div that is only relevant in the
Foo's view (a la 'page.replace_html
'some_div_id_in_foos_show_rhtml' ...).

Alternatively, one could drop an update_bar_context1.rjs in views/
foos. The div id contained therein will reference some div relevant
to Foo, which is nice, but having the BarsController reference an RJS
outside of its own view space likewise seems a bit dirty.

I have to think that there are others out there who are doing some
AJAX-heavy nested resource editing. What pattern(s) have you
followed? You know, I don't actually own the Recipes book. Is there
a Recipe in there for this scenario?

Thanks in advance, all.

- BD

Brian Dainton wrote:

In a nutshell:

I've got 2 RESTful resources and complex edit page for the parent
resource. I want to modify the nested resource from the parent
resource's edit page, and I want to use AJAX to do it. I'm having a
really hard time finding a clean way to organize the RJS and partials
artifacts.

More detail:

I'm writing a RESTful Rails app and I'm bumping into almost exactly
the same xhr context problem described at the very end of this post...

    http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/59998e003c538743

...and in this July, 2006 blog post from Bruce Williams...

    http://codefluency.com/2006/7/1/rails-views-getting-in-context

Question 1: Have there been any additions to core Rails that address
this context problem?
  

Not that I know of.

More than anything, I feel like this context issue has introduced a
lot of codebase uncleanliness. Uber-quick example:

I have a Foo resource with a nested Bar resource.
>From a form in foos/show.rhtml, I want to update the nested Bar
resource via BarsController:update.

Great...so, I hit the update action in the BarsController. In my
respond_to, I do a switch on the appropriate context and then render a
context-specific RJS.

Question 2: Where should these context-specific RJS files live? Under
views/bars or views/foos?

I think the common approach would be for (say) update_context1.rjs to
live under views/bars. It really bugs me, though, that this file is
going to contain a div id for some div that is only relevant in the
Foo's view (a la 'page.replace_html
'some_div_id_in_foos_show_rhtml' ...).

Alternatively, one could drop an update_bar_context1.rjs in views/
foos. The div id contained therein will reference some div relevant
to Foo, which is nice, but having the BarsController reference an RJS
outside of its own view space likewise seems a bit dirty.

I have to think that there are others out there who are doing some
AJAX-heavy nested resource editing. What pattern(s) have you
followed? You know, I don't actually own the Recipes book. Is there
a Recipe in there for this scenario?
  

I've run into some of the same problems. I'm beginning to to think the
answer may be to move from RJS to a more client-side JS interface. Why
should the controller/action need to know everywhere it is called from
and how to update those pages. It would make more sense to keep the
RESTful controller simple and put the view logic in the view. Take a
look at Jester
(http://giantrobots.thoughtbot.com/2007/6/11/jester-1-3-jsonic-rest). It
is implementing ActiveResource in JS. You can retrieve the data object
instead of just instructions on how to rewrite the page. Then the page
that requested the CRUD operation can alter itself as it sees fit
without the controller needing any knowledge of where it was called from.

I've not gone very far down this road so I don't know all the potholes
that await, but the dabbling I've done has gone well so far.

Jack

Thanks for the response, Jack. I'll take a look at Jester.

Has anyone else out there seen/built a RESTful app with this type of
behavior (modifying a nested resource via AJAX from a parent resource
page)? I'd love to see an example of its structure.

- BD