I used the "Cleaning Up Controllers with Postback Actions" recipe from
Rails Recipes. Basically you replace all the edit/new/update/create
methods with one method that looks like:
def edit
@recipe = Recipe.find_by_id(params[:id]) || Recipe.new
if request.post?
@recipe.attributes = params[:recipe]
redirect_to :main_url and return if @recipe.save
end
end
My form uses form_for with a url parameter:
<% form_for(@schedule, :url => {:action => ''edit''})
do |f| %>
When I create a new entry and submit the form, it does a POST just
like you''d expect, but when I edit an existing record and submit the
form, the server claims it is doing a PUT. That means no updates since
the record is only updated when the browser submits a POST action.
Even the source in the browser claims the form is going to be
submitted with a POST, but by the time it gets to the server, the
server log claims it is a PUT. Any ideas? I''ve hacked around it for
now by checking for POST or PUT but that feels, well, hacky.
Frankly I''m a little disappointed in the recipe. For it to work,
you''ll need to change your form and possibly your routes.rb file, but
those details are left out :(
--
Curtis Cooley
curtis.cooley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
==============Leadership is a potent combination of strategy and character. But
if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
I haven''t looked at the recipe you refer to but most browsers will only do posts. That''s why Rails form helpers simulate doing a put by adding a hidden field called _method to the form which rails then checks for before passing control onto your controller. PUTs *are* supposed to be used to update your records but the RESTful way of doing it is to put the update code in the update method and specifying resources in your routes.rb file. Also using the REST convention, your edit method should respond to a GET and should display a form. It shouldn''t be updating anything. This guide should set you on the right track: http://guides.rubyonrails.org/getting_started.html Regards Ritchie On Jan 12, 8:24 am, Curtis Cooley <curtis.coo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I used the "Cleaning Up Controllers with Postback Actions" recipe from > Rails Recipes. Basically you replace all the edit/new/update/create > methods with one method that looks like: > > def edit > @recipe = Recipe.find_by_id(params[:id]) || Recipe.new > if request.post? > @recipe.attributes = params[:recipe] > redirect_to :main_url and return if @recipe.save > end > end > > My form uses form_for with a url parameter: > <% form_for(@schedule, :url => {:action => ''edit''}) do |f| %> > > When I create a new entry and submit the form, it does a POST just > like you''d expect, but when I edit an existing record and submit the > form, the server claims it is doing a PUT. That means no updates since > the record is only updated when the browser submits a POST action. > Even the source in the browser claims the form is going to be > submitted with a POST, but by the time it gets to the server, the > server log claims it is a PUT. Any ideas? I''ve hacked around it for > now by checking for POST or PUT but that feels, well, hacky. > > Frankly I''m a little disappointed in the recipe. For it to work, > you''ll need to change your form and possibly your routes.rb file, but > those details are left out :( > > -- > Curtis Cooley > curtis.coo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > home:http://curtiscooley.com > blog:http://ponderingobjectorienteddesign.blogspot.com > ==============> Leadership is a potent combination of strategy and character. But if > you must be without one, be without the strategy. > -- H. Norman Schwarzkopf-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Jan 11, 2010 at 9:57 PM, Ritchie <ritchiey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I haven''t looked at the recipe you refer to but most browsers will > only do posts. That''s why Rails form helpers simulate doing a put by > adding a hidden field called _method to the form which rails then > checks for before passing control onto your controller. > > PUTs *are* supposed to be used to update your records but the RESTful > way of doing it is to put the update code in the update method and > specifying resources in your routes.rb file. > > Also using the REST convention, your edit method should respond to a > GET and should display a form. It shouldn''t be updating anything. > > This guide should set you on the right track: http://guides.rubyonrails.org/getting_started.html >Ok, so the recipe allows you to replace 4 similar methods with one method, which is more DRY, but from what Ritchie is saying, adhering to the RESTful interface is more important. Is it ''better'' to keep the four methods and DRY them up as best I can rather than trying the post back method recipe? I''m thinking so, since the post back recipe made me do some things I didn''t really like, like removing the resources entry from my routes. And it broke things. Plus, I just discovered that the "Rails Recipes" book is for Rails 1.0. Sheesh, I just bought it :( Perhaps the post back model isn''t encouraged any more despite it''s DRYness. -- Curtis Cooley curtis.cooley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org home:http://curtiscooley.com blog:http://ponderingobjectorienteddesign.blogspot.com ==============Leadership is a potent combination of strategy and character. But if you must be without one, be without the strategy. -- H. Norman Schwarzkopf -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Curtis Cooley wrote:> On Mon, Jan 11, 2010 at 9:57 PM, Ritchie <ritchiey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> GET and should display a form. It shouldn''t be updating anything. >> >> This guide should set you on the right track: http://guides.rubyonrails.org/getting_started.html >> > > Ok, so the recipe allows you to replace 4 similar methods with one > method, which is more DRY, but from what Ritchie is saying, adhering > to the RESTful interface is more important. > > Is it ''better'' to keep the four methods and DRY them up as best I can > rather than trying the post back method recipe? I''m thinking so, since > the post back recipe made me do some things I didn''t really like, like > removing the resources entry from my routes. And it broke things. > > Plus, I just discovered that the "Rails Recipes" book is for Rails > 1.0. Sheesh, I just bought it :( > > Perhaps the post back model isn''t encouraged any more despite it''s > DRYness.Yeah, this looks like a mediocre idea. If you want to avoid repetition in your controllers, I''d suggest something like make_resourceful.> -- > Curtis Cooley > curtis.cooley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > home:http://curtiscooley.com > blog:http://ponderingobjectorienteddesign.blogspot.com > ==============> Leadership is a potent combination of strategy and character. But if > you must be without one, be without the strategy. > -- H. Norman SchwarzkopfBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. --0015174c0d5ca0ff7f047cfaa26c Content-Type: text/plain; charset=ISO-8859-1 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. --0015174c0d5ca0ff7f047cfaa26c--