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

rubyonrails-talk
1

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

2

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 (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

3

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