Redirect to edit form after update

rubyonrails-talk
1

By default, the controllers are coded in a way that you will be redirected to the SHOW page of the item you are updating.

For example, if I edit a user, after I click the submit button, I will be redirected to the SHOW page of that users.

Instead of being redirected to the SHOW page, I want to stay in the same EDIT page with a notice that the user has been updated. How can I accomplish that?

I tried this... format.html { redirect_to(:action => 'edit' , :notice => 'User was successfully updated.') }

And it did get me redirected to the EDIT form. But I don't see the notice message and the resulting URL is this: http://localhost:3000/users/4/edit?notice=User+was+successfully+updated.

So I must be doing something wrong.

2

By default, the controllers are coded in a way that you will be redirected to the SHOW page of the item you are updating.

For example, if I edit a user, after I click the submit button, I will be redirected to the SHOW page of that users.

Instead of being redirected to the SHOW page, I want to stay in the same EDIT page with a notice that the user has been updated. How can I accomplish that?

I tried this... format.html { redirect_to(:action => 'edit' , :notice => 'User was successfully updated.') }

You don't want the :notice bit, just make sure that the flash is shown on the edit page as it is on the show page. Probably something like <p style="color: green"><%= flash[:notice] %></p> in the layout. and set flash[:notice] in the update action (which it probably is already).

Colin

3

ALRIGHT!! AWESOME!!!

Simple and it works!

I did this...

flash[:notice] = 'User was successfully updated.' respond_to do |format|   if @user.update_attributes(params[:user])     format.html { redirect_to(:action => 'edit') }     format.xml { head :ok }   else ...

Thanks Colin!

4

There is a shorthand for specifying the "notice" flash in the redirect_to call. You were very close to having it correct.

The format is this: redirect_to(options = {}, response_status = {})

The :notice needs to be in the response_status hash.

The problem you had is that that :action and :notice were both passed in the options hash. You can use the shorthand by explicitly separating the hashes:

redirect_to( { :action => 'edit' }, :notice => 'User was successfully updated.' )

5

I have come in this conversion late but I can still contribute.

You may wish to know whether the user was sucessfully updated or not. So I guess (1) your flash[:notice] is ill-positioned, and (2) you need to have an “error dispatcher” too. In addition, I am not sure if you “really” want to conditional processing of HTTP (I mean do you really need to specify that the application should respond to html format?).

But combining the solutions above (from the previous threads) plus my changes, we have the following:

  1. In you controller:

respond_to do |format|

if @user.update_attributes(params[:user])

flash[:notice] = ‘User was successfully updated.’ format.html { redirect_to(:action => ‘edit’ ) }

else

flash[:error] = ‘User was not updated.’ format.html { redirect_to(:action => ‘edit’ ) }

end

end

  1. In your layout, you may wish to add the following lines to track the “flash” messages:

<%= flash[:notice] %>

<%= flash[:error] %>

More blessings,

6

Thanks :slight_smile: I just removed the XML part and yes I did notice I had the flash in the wrong position haha.

What do you mean by "I am not sure if you "really" want to conditional processing of HTTP"?

I'm sorry if the question seems very basic, I'm barely getting familiar with Ruby.

7

Thanks :slight_smile: I just removed the XML part and yes I did notice I had the

flash in the wrong position haha.

What do you mean by "I am not sure if you “really” want to conditional

processing of HTTP"?

The sentence may not be clear somehow. I realize that the other bit was a semantic issue. :slight_smile: But you have already answered this part by removing the xml section. Then, I’m sure your code contains no respond_to block. It looks very clean that way (unless you want your app to respond conditionally to HTTP requests send to it. (Oh my! this comes up again) Conditional processing happens in the respond_to block. In other words, you would want your application to do something when it is xml, another thing when it is an HTML, and the other thing when it is a PDF: Thus processing conditonally the page depending on the “page formats”.

8

So instead of

9

Leonel *.* wrote in post #965703: [...]

I had the respond_to block because that's how it was programmed by the scaffold and wasn't sure if I should remove it or not.

Yet another reason not to use scaffolding: it generates a lot of junk that you won't understand if you're a beginner and you won't need if you're experienced...

(It *can* be useful as an example, though.)

Best,

10

Leonel *.* wrote in post #965703:

So instead of ----------------------------------------    respond_to do |format|       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end     end ---------------------------------------- Should I do this? ----------------------------------------       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end ----------------------------------------

If you did that, where would the local variable "format" be defined?

Best,

11

Marnen Laibow-Koser wrote in post #965706:

Leonel *.* wrote in post #965703:

So instead of ----------------------------------------    respond_to do |format|       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end     end ---------------------------------------- Should I do this? ----------------------------------------       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end ----------------------------------------

If you did that, where would the local variable "format" be defined?

Well, you're right, but Edmond said: "But you have already answered this part by removing the xml section. Then, I'm sure your code contains no *respond_to* block. It looks very clean that way (unless you want your app to respond conditionally to HTTP requests send to it."

12

Leonel *.* wrote in post #965713:

Marnen Laibow-Koser wrote in post #965706:

Leonel *.* wrote in post #965703:

So instead of ----------------------------------------    respond_to do |format|       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end     end ---------------------------------------- Should I do this? ----------------------------------------       if @user.update_attributes(params[:user])         flash[:notice] = 'User was successfully updated.'         format.html { redirect_to(:action => 'edit') }       else         flash[:error] = 'User was not updated.'         format.html { render :action => "edit" }       end ----------------------------------------

If you did that, where would the local variable "format" be defined?

Well, you're right, but Edmond said: "But you have already answered this part by removing the xml section. Then, I'm sure your code contains no *respond_to* block. It looks very clean that way (unless you want your app to respond conditionally to HTTP requests send to it."

That doesn't mean you can remove it with no other modifications. You've got to understand the Ruby syntax, not just use it like a cookbook. :slight_smile:

If you want to try it, go ahead. And watch your automated tests turn bright red...

Best,

13

So instead of

respond_to do |format|

  if @user.update_attributes(params[:user])

flash[:notice] = ‘User was successfully updated.’

    format.html { redirect_to(:action => 'edit') }

else

    flash[:error] = 'User was not updated.'

format.html { render :action => “edit” }

  end

end

Should I do this?

Remove the format sections. You can do without it them. Your application knows how to handle html by default.

if @user.update_attributes(params[:user])

flash[:notice] = ‘User was successfully updated.’

     redirect_to(:action => 'edit')

else

    flash[:error] = 'User was not updated.'

render :action => “edit”

  end

I had the respond_to block because that’s how it was programmed by the

scaffold and wasn’t sure if I should remove it or not.

Scaffold is a nice thing but … as Marnen Laibow-Koser wrote:

Yet another reason not to use scaffolding: it generates a lot of junk

that you won’t understand if you’re a beginner and you won’t need if

you’re experienced…

(It can be useful as an example, though.)

I do not want to start a scaffolding fight here, but scaffolding often creates code that is untidy and eventually becomes unreadable even to the developer. You can do without it.

I’m sorry if the question seems very basic, I’m barely getting familiar with Ruby.

This should be a good reason enough to keep scaffolding on hold. You would probably need to practice coding yourself rather than letting a generator do the coding for you. More blessings,

14

Thanks a lot guys. Yes, I'll try to understand Ruby syntax more. I studied the PDF of the unfinished version of the new Agile Web Development with Rails. After that, I bought the pickaxe Programming Ruby 1.9 book and I'm barely getting into it.

Thanks