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.’) }
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:
Le 1 dcembre 2010 18:12:01 UTC+2, Leonel .[email protected] a
crit :
format.xml { head :ok }
else
…
Thanks Colin!
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:
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
In your layout, you may wish to add the following lines to track the
“flash” messages:
Thanks 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. 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”.
I’m sorry if the question seems very basic, I’m barely getting familiar
with Ruby.
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…
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
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.
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?
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.
If you want to try it, go ahead. And watch your automated tests turn
bright red…
Remove the format sections. You can do without it them. Your
application
knows how to handle html by default.
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.
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.
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.”
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.