Brian Dainton
2007-Jun-11 15:51 UTC
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Jack Christensen
2007-Jun-12 04:18 UTC
Re: Standard practices for RESTful remote (AJAXified) manipulation of nested resources?
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 in advance, all. > > - BD > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Brian Dainton
2007-Jun-12 14:27 UTC
Re: Standard practices for RESTful remote (AJAXified) manipulation of nested resources?
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 On Jun 11, 11:18 pm, Jack Christensen <j...-BsDU1ACF2Bglk5EcyZIkJQ@public.gmane.org> wrote:> 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/... > > > ...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 in advance, all. > > > - BD--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---