From what I understand, link_to is used for get methods, and button_to is used for post methods.
On the other hand, I was told that with HTML5 semantics, <button> is used for any type of clickable...well, button. In the case I have a clickable button that sends a user to a form to fill out, should I create a button_to or a link_to?
It's simpler that you think.
That methods are Rails helpers and don't have anything to do with haml.
Yes, one method is for get and another for post methods. If you need to post any data to controller, use button_to (for example when deleting a record). Otherwise, link_to is enough.
Moreover, you can make link_to posting data using :method parameter:
= link_to "Something", some_path, :method => :post
Answering your question, use link_to.
The main principle difference between the #link_to, and #button_to is that the #link_to just creates a link tag A, and makes simple AJAX request without an additional data, while #button_to creates a FORM with a custom data, so the form can be used to make extended AJAX request to a webserver. The form data includes embedded CSRF-token, which is used to authentication the request. In case of #link_to CSRF-token must be serualized and send in on_click event.
You should use links to point the user to a resource, like an article.
But you have to tend to use buttons to point to an action(like "Create"/"Send" on your edit page). If this doesn't agree with your interface -- style them like as a link.
Here's why: you cannot point your user to any non-GET action via link_to if he lacks the javascript support. So, buttons are the only options to make your send/destroy action to be triggered in this case.
Feel free to use both approaches if your link points to a page that eventually leads to a modification of a resource (link/button to an edit/create page that shows a form), like in your case.
If you want to simply send a user to somewhere, it is get request. So you should use link_to in this case. By the way, you can use the link_to for post requests and other requests (like button_to too) if you will specify :method. For example: =link_to "some path", some_path, :method => :get
Related
Rails provides data-disabled-with for button tags on form submits. Super awesome. However, link tags don't get this desired behavior. They're great to prevent users from clicking a button too many times and producing an unwarranted effect.
Is there a way I can do something like:
Purchase me
Rails provides this functionality via the :disable_with parameter of the link_to helper. See docs.
For example:
link_to("Create", create_post_path(#post), remote: true, disable_with: "Creating...")
Recognizing of course that creating a resource via a GET request isn't idiomatic Rails/REST... but this hopefully illustrates how it could be used.
i need to create a link in my rails view that basically takes the user from the normal http page to the same page but using https.
i currently have something like
CLICK ME!
however it:
does not include the parameter string
just looks hack-ish to me
is there a better way to take the user from http to the same relative request path with all of the parameters?
Try something like
<%= link_to "CLICK ME!", named_url(protocol: 'https') %>
Where named_url is the route to whatever you want to link to.
EDIT
Since you don't have a named route and just want to use whatever page the user is on, you can do something like:
<%= link_to "CLICK ME!", "https://#{request.host}#{request.fullpath}" %>
You can find more about the request object here: http://guides.rubyonrails.org/action_controller_overview.html#the-request-object
when i read the book "Aglie web development with rails 4th",i found the code
<%= button_to 'Add to Cart', line_items_path(:product_id => product) %>
what's the difference if i use "line_items_url" and the code doesn't has the method like :method=>:post,
why?
The path version produces relative urls such as /order/34/lines/ while the url version produces a full url such as http://localhost:3000/order/34/lines/.
The second form is often used in mailers when the user click a link in a mail client or in an external webmail.
In your site you won't notice any difference.
Moreover the :method=>:post option will produce a post request to your webserver. It will do that by adding a javascript code which will create a form on the fly, add parameters to it and do a submit call to send your browser to the requested page with a post method.
The _url helper generates an URL that includes the protocol and host
name. The _path helper generates only the path portion.
Rails 3 does some cool stuff to make Javascript unobtrusive, so they've done things like this:
= link_to "Logout", user_session_path, :method => :delete
..converts to
Logout
But it just occurred to me.. When I turn off javascript the method isn't DELETE anymore, it's GET as expected. So are there plans to, or is there some way to, allow these data- attributes to degrade gracefully, so that link still is a DELETE request?
The change they made in Rails 3 with these data- attributes wasn't about graceful degradation, it was about unobtrusive JavaScript.
In Rails 2, specifying :method => :delete on a link would generate a whole bunch of inline JavaScript that would create a form with a hidden input and then submit the form. That was the same as it is now: turn off JavaScript and it defaults to a GET request. As such, supporting the case of no JavaScript is the same as it was before.
One option is to use a form/button instead of a link so you can include the method as a hidden field, much like the Rails 2 JavaScript does. Another option is to have the GET version take you to an intermediate page which in turn has the form/button.
The benefit of the new approach is that it's unobtrusive. The JavaScript for changing the HTTP verb exists in an external file and uses the data- attributes to determine which elements it should be attached to.
Rather than using the link_to method -- which would require you use JavaScript to ensure that the HTTP method is DELETE -- use the button_to method, which will create a form with a hidden input element which tells Rails to treat the HTTP method as DELETE rather than POST. If necessary, you can then use CSS to style the button in the form so that it looks like a link.
The only chance you have is define a form. A link can't be a POST with _method="delete" without Javascript or by form.
It is not possible without javascript.
I make a small jQuery plugin for converting data-method link attribute to pseudo hidden forms (used in laravel project for example).
If you want to use it : https://github.com/Ifnot/RestfulizerJs
I have a list view in my RoR web app. The view is a result of a scaffold operation.
I want to add a button that will refresh the page. I prefer not to use javascript for this one, is there another way?
Creating a button via button_to or form_tag ends up adding a new blank row in the database when it is clicked.
Thanks!
Shay.
I am going to assume that you are using standard RESTful routes and as a result your form/button_to calls are POSTing to you controller and therefore executing your create action. If that is the case then either of the options you tried should work, but just make sure you are setting the method to "get" so the request is routed to the index action correctly
<%= button_to "Refresh", my_path, :method => :get %>
1) Use a link and dress it up as a button w/ CSS
or
2) Use a form whose method is "get", points to the current page (without any params) as the action and has only one element, a submit button?