I''m working on an application (on Edge Rails) that has a really long user profile page - viewed, of course, with a GET to /users/:id. The editing side of things needs to be broken up into four logically-grouped screens - say, contact info, work history, education, and personal info. These screens are essentially update-only - their "show" counterpart is the whole profile at /users/:id. And the update can only be performed by current_user, so the :id is superfluous. There is no Create function, and there is no Delete function. So far, I see only two choices: 1. Don''t use RESTful routes at all. Change the GET to /users/show/:id, and do the updates with POSTs to /users/edit_contact_info, /users/edit_education, etc. Put it all in users_controller. This is the path I''ve been taking, but it loses some of the simply_helpful magic. 2. Create RESTful routes, and manually draw them in routes.rb. This seems brittle, and I have to lie about (e.g.) "contact_info" belonging to the collection instead of the member, since I don''t want the :id in the URL. Plus, I think that means each of the four mini-edit pages has to go in its own, one-action controller! Ugly. Is there a third way? Jay Levitt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Sure. The Rails implementation of REST allows you to extend the
RESTful routes with a similar concept to choice #2 but without
"lying."
Say you want a unique url that updates _only_ the contact_info of a
user. You can extend the user routes in routes.rb like this:
map.resources :users, :member=>{:update_contact_info_of=>:post}
What this says is that there should be a url for an individual user
resource (a _member_ of the users collection) with an action mapping
to "update_contact_info_of" that accepts only POST data. Just in case
it''s not obvious, :member is a hash for defining actions for
individual resources, keyed by the name of an action and with a value
of the allowed http methods (:get, :put, :post, :delete, :any).
By extending the users routes in that way, the form_for that wraps the
contact info can looks like this:
<% form_for :user, update_contact_info_of_user_path(@user) do |f| %>
...
<% end %>
HTH,
AndyV
On Aug 20, 10:33 pm, Jay Levitt <j...-WxwZQdyI2t0@public.gmane.org>
wrote:> I''m working on an application (on Edge Rails) that has a really
long user
> profile page - viewed, of course, with a GET to /users/:id.
>
> The editing side of things needs to be broken up into four
> logically-grouped screens - say, contact info, work history, education, and
> personal info. These screens are essentially update-only - their
"show"
> counterpart is the whole profile at /users/:id. And the update can only be
> performed by current_user, so the :id is superfluous.
>
> There is no Create function, and there is no Delete function.
>
> So far, I see only two choices:
>
> 1. Don''t use RESTful routes at all. Change the GET to
/users/show/:id, and
> do the updates with POSTs to /users/edit_contact_info,
> /users/edit_education, etc. Put it all in users_controller. This is the
> path I''ve been taking, but it loses some of the simply_helpful
magic.
>
> 2. Create RESTful routes, and manually draw them in routes.rb. This seems
> brittle, and I have to lie about (e.g.) "contact_info" belonging
to the
> collection instead of the member, since I don''t want the :id in
the URL.
> Plus, I think that means each of the four mini-edit pages has to go in its
> own, one-action controller! Ugly.
>
> Is there a third way?
>
> Jay Levitt
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
On Aug 21, 2007, at 8:59 AM, AndyV wrote:> Say you want a unique url that updates _only_ the contact_info of a > user. You can extend the user routes in routes.rb like this: > > map.resources :users, :member=>{:update_contact_info_of=>:post} > > What this says is that there should be a url for an individual user > resource (a _member_ of the users collection) with an action mapping > to "update_contact_info_of" that accepts only POST data. Just in case > it''s not obvious, :member is a hash for defining actions for > individual resources, keyed by the name of an action and with a value > of the allowed http methods (:get, :put, :post, :delete, :any).To me, this smells like RPC. There''s a verb in your URL, "update". You don''t need that, you''ve already said you''re updating because of PUT. What I would do is define a singleton resource for profile. map.resource :profile The view for that profile is broken up, I gather from the original question, into multiple forms. They can all PUT to the same reasource, though, /profile. There''s nothing that says a PUT/update has to include ALL the data for the resource. Personally, I would add extra bits onto my profile resource, so a GET of /profile/contact_info would show the view for editing the contact info and /profile/work_history would show the view for editing the work history. Rails routing is extremely flexible. There is almost never a "has to go somewhere I don''t want it to" with Rails routing. HTH, Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
See below... Michael D. Ivey wrote:> On Aug 21, 2007, at 8:59 AM, AndyV wrote: > >> Say you want a unique url that updates _only_ the contact_info of a >> user. You can extend the user routes in routes.rb like this: >> >> map.resources :users, :member=>{:update_contact_info_of=>:post} >> >> What this says is that there should be a url for an individual user >> resource (a _member_ of the users collection) with an action mapping >> to "update_contact_info_of" that accepts only POST data. Just in case >> it''s not obvious, :member is a hash for defining actions for >> individual resources, keyed by the name of an action and with a value >> of the allowed http methods (:get, :put, :post, :delete, :any). >> > > To me, this smells like RPC. There''s a verb in your URL, "update". > You don''t need that, you''ve already said you''re updating because of PUT. > > What I would do is define a singleton resource for profile. > > map.resource :profile > > The view for that profile is broken up, I gather from the original > question, into multiple forms. They can all PUT to the same > reasource, though, /profile. There''s nothing that says a PUT/update > has to include ALL the data for the resource. > > Personally, I would add extra bits onto my profile resource, so a GET > of /profile/contact_info would show the view for editing the contact > info and /profile/work_history would show the view for editing the > work history. > >You could also map.resources :users, :collection => {:contact_info => :put}> Rails routing is extremely flexible. There is almost never a "has to > go somewhere I don''t want it to" with Rails routing. > > > HTH, > Michael > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---