I am trying a simple download from a server. This is using Rails 5.01, Ruby 2.24p230.
The view has a link to the controller to download data. It gets there just fine.
The controller method is just this:
def download
send_data("some sample text", filename:sample.txt)
flash[:success] = "it worked"
end
The result is that a file is named sample.txt containing the correct text is downloaded to the client. flash never happens. The view which linked to the controller is still on the screen, without any page refresh. A view called "download.html.erb" is never called.
My questions are:
Is there a simple way to cause some communication with the client following the send_data? It would be nice to tell the person on the client something after a successful download.
After the send_data, what should happen?
Thank you for taking the time to answer this.
To understand what is going on here you have to understand how the session and flashes work.
A flash message is stored in the session and carried on to the next request. When the request is finished flash messages from the previous request are removed from the "flash hash" which is stored in the session.
class TestController
# GET /foo
def foo
flash[:notice] = "Hello"
redirect_to '/bar'
end
# GET /bar
def bar
flash.now[:alert] = " world!"
end
end
So when the user requests /foo they are redirected to /bar and the flash hash will contain:
{
notice: "Hello",
alert: " world!"
}
So how is this relevant? When the client clicks the download button the flash message you set will be seen in the next request they perform. Which is not really that useful. Instead what you want to do is probably just use javascript and display a popup or some sort of message when the user clicks the download link.
When you send data to the client few will actually allow you to set any kind of redirect to be followed or will ignore any headers you send. This is because the huge number of potential annoying or malicious uses.
Related
When a user makes an invalid create request for a resource, I want to send them back to the form and show them an error. As far as I can tell, calling render "new" is the standard way to do it.
This seems like a bad idea to me, because the create request has taken the user to /resources, whereas my "new" form is otherwise at /resources/new. If I use render "new", the URL in the address bar will not reflect what the user sees. If they make a GET request there, they'll end up on a different page.
I thought I could solve this problem by using redirect_to new_[resource]_path, but if I do that I lose access to the form data and errors. Surely this is not an uncommon problem. Is there a better way to deal with it?
I have the same problem with edit/update and other form/submit action pairs.
TL;DR:
class ResourcesController < ApplicationController
def new
#resource = Resource.new(resource_params)
if resource_params.present?
#resource.validate
end
end
def create
#resource = Resource.new(resource_params)
if #resource.save
redirect_to #resource, notice: 'Resource has been created'
else
redirect_to new_resource_url(resource: resource_params)
end
end
private
def resource_params
params.fetch(:resource, {}).permit(...)
end
end
I asked this myself as well in my early beginner days, on why Rails scaffold generator generates the def create action to render :new if saving failed, instead of redirecting to the correct URL just something like above, which would confuse the users because their URL would have changed from /resources/new into /resources even though they would still see the exact same Resource form on the page, and therefore they would not be able to reload the page or copy this /resources URL (for example, if they want to share this URL to someone else), because should they share this /resources URL, the others would see a list of Resources on the page instead of what the original user would have expected to see from the copied URL: which is the form page.
After the user submits the form, the URL they see on the address bar should have changed into POST http://localhost:3000/resources instead of just simply http://localhost:3000/resources. The browser hides the HTTP Method being used, that's why this leads to their possible confusion that /resources seems to have been both sometimes: a form page, sometimes a list of resources page. However, speaking of UX, every time anyone enters something or pastes something in the URL address bar of the browser, it is always automatically implied to be doing a GET request. Therefore, it makes sense for the browser-developers to just simply hide the HTTP method (i.e. GET in particular) from the users as to not confuse them.
From my answer above, I only used something like this once before (because there was a certain action that demanded me not to change the URL from the referrer form page). However, I normally render :new instead of redirect_to new_resources_url, simply because:
a redirect_to new_resource_url(resource_params) would take twice as much time and data-transmitted than simply rendering :new. Why? Because you redirect (opening up a new request) with the exact same parameters anyway. Just imagine if your form page is soooo big, and has so many input fields.
and also that there's a limit to how long a URL can be, of which won't guarantee to work if you have a very big form with very long text fields. See this SO
Updated:
As you have said though, why not just POST /resources/new instead of POST /resources when the form is submitted, right? This will solve the redirect_to new_resource_url(resource_params) problem I've shown above, because the URL after form-submit would have been the same and you can just simply render :new, then. And I actually agree on that, and I've used something like this also before long time ago. The main reason I don't use this is that it is not inline with REST standards. That is: POST /resources/new means that you're creating a Resource object "inside" the resources/new location, which then means by REST, after submitting the form, I would and should be able to access this newly created resource by doing something like GET /resources/new/the_newly_created_record, except that... you can't.
But you can still use POST /resources/new, although I would not recommend it on a normal Rails application like yours, and however strictly discourage it on an API-based Rails application.
You may be overthinking this. How about get /resources the index page vs post /resources the create action? Same url in the address bar!
It's not a problem. Neither a technical problem or an aesthetic problem.
render "new" means: render this template, not: go to this route. And although templates often have the name of the corresponding action, it's not a requirement.
Here is my create action. It creates a new instance of Message, which is checked with model validations.
Then there is a simple if else loop that sends the message if the model validations were fulfilled and renders the 'new' view if they want to send another. If the model validations weren't fulfilled, it simply renders the 'new' view again.
The flash hash is also populated with relevant information, a success message and an alert message if the message was successful or not.
def create
#message = Message.new(message_params)
if #message.valid?
Contactform.contact(#message.name, #message.town, #message.email, #message.content).deliver
flash[:success] = "Sent message"
render 'new'
else
flash[:alert] = "Alert"
render 'new'
end
end
However, I don't think I'm doing it right, because the messages stay in the flash. They aren't cleared after they've been viewed once.
How should I ensure that the flash is cleared, as it should be?
Update
This is how the error comes about. I send a message successfully, and I'm routed back to the 'new' view and I receive a 'success' flash. I attempt to send an erroneous message, and I'm routed back to the 'new' view and I receive both the 'success' flash from before, and a 'alert' flash. Very confusing for the user!
The second I browse to another page, both flashes disappear, but that's the problem I think. Something to do with coming back to the same page so Rails doesn't know to clear the flash. Can I force clear the flash?
I think reading the section about flash.now in the rails doc will help clear this up for you: http://guides.rubyonrails.org/action_controller_overview.html#flash-now.
Flash sticks around for the next request. In this case, you aren't issuing a new request after your create action - you are just re-rendering the new view. I think flash.now is what you want to be using here.
I would also say that in your create success case, the create action should be doing a redirect rather than just re-rendering the view. Are redirect_to and render exchangeable? explains the difference between redirecting and rendering
I want to be sure that the data I receive came from a specific page (it's for a navigator game).
I would prefer a solution using RoR but if we can do it with JS it's ok =)
In your controller, you have access to the request variable (type of ActionDispatch::Request) which represents the actual request received by your server:
def index
puts request.inspect # see in your server's console the output
# ...
end
With this variable, you can access to the referer, which returns the path (as String) of the last page seen, or nil if you came from another domain (or blank page).
To check which page sent your form, you could use:
def my_controller_action
if request.referer.present? && request.referer.include?('/string/to/check/')
# yay!
else
# well, the request is not coming from there
end
end
You could also set it as a before_filter in your controller in order to check "quietly" the requests and not in each controller's action.
A tutorial I am following has the below code which it mentions is not quite right because the error flash persists one request longer than desired because render doesn't count as a request. The solution is to use flash.now instead.
But how is it even possible for the error flash to persist one extra request? Given that Rails is stateless how is the information of the flash stored for the next request?
class SessionsController < ApplicationController
def new
end
def create
user = User.find_by_email(params[:session][:email].downcase)
if user && user.authenticate(params[:session][:password])
# Sign the user in and redirect to the user's show page.
else
flash[:error] = 'Invalid email/password combination' # Not quite right!
render 'new'
end
end
def destroy
end
end
Use flash.now instead of flash.
The flash variable is intended to be used before a redirect, and it persists on the resulting page for one request. This means that if we do not redirect, and instead simply render a page, the flash message will persist for two requests: it appears on the rendered page but is still waiting for a redirect (i.e., a second request), and thus the message will appear again if you click a link.
To avoid this weird behavior, when rendering rather than redirecting we use flash.now instead of flash.
The flash is stored in the user's Session, which is associated with them on subsequent requests using HTTP cookies. The flash is just one part of the session whose data is automatically flushed on the next request. See the Rails Guide to Action Controller for more details.
My basic use case is do some processing, set flash[:notice], and then redirect to a new page. From what I can tell, redirects reset the flash tag (please correct me if I'm wrong). Is there a way to gain persistence? Using sessions isn't an option, and I have hacked around the problem using cookies, but I think there's got to be a better way.
The flash hash persists for exactly one redirect or render. So you should be fine with the default settings.
If you need to keep the flash hash for another request/redirect, you can call flash.keep.
flash.keep # keep the entire flash hash around for an extra request.
flash.keep(:notice) # keep just flash[:notice] for an extra request.
Something to be aware of in at least Rails v3.2.1 is that the flash will persist through a redirect if its not referenced at all through at least 1 redirect and load the same view after. This is a pseudo code of my recent experience:
def some_action
(code that may set a flag to redirect 1 time)
redirect_to action_path if(redirect_flag)
....
end
Running this would result in the flash[:message] being present regardless of the redirect.
def some_action
logger.debug("Flash[:message] #{flash[:message]}")
(code that may set a flag to redirect 1 time)
redirect_to action_path if(redirect_flag)
....
end
During debugging with the logger referencing flash[] it would only show up when the redirect didn't happen. I could see this being problematic if you added a reference to flash before a redirect and lost it down the line for no apparent reason.
See ruby docs here (Instance protected method: Use at the bottom)