Friday, October 28th, 2005
Ruby on Rails uses Ajax to simulate POST links
Category: Ruby
David Heinemeier Hansson wasn’t happy when he saw Google Web Accelator was back in action, and more deadly.
He wrote about how Rails is more prepared this time around and the interesting part from an Ajax side is how Rails has added a high level abstraction that gives you links via get or post.
link_to
Rails has a helper names link_to that builds <a href> links for you. Unfortunately in HTML, we don’t have a way to say “do this link as a post” by doing something like:
<a href=”…” method=”post”>
If you are using Rails, you do get this ability with a change to link_to that allows you to simply add :post => true.
Behind the scenes Rails will build the JavaScript to do an Ajax request via post.
“But what if the user doesn’t have JavaScript turned on?” I hear you cry. In this case it gracefully falls back to a get.
button_to
There is also a new button_to.
If you want to be a real pretty momma’s boy, you can use the new button_to, which just makes it easy to create a mini-form that’ll submit to the chosen URL as POST. But that generates a real, visible form, which despite being subject to styling, is often not something that’s easy to fit into an application design of your choice.
Yes, but you can also use: form { margin: 0; } in your css to reduce the havok a form tag can do on your layout.
(See http://korrespondence.blogspot.com/2005/11/link-is-not-widget.html)
This hack is purely to make a button in the user interface not look like a button. The problem is that most of the operations this is intended to be used with are ‘remove’ or ‘delete’ type of operations - actions that a user really really should know about ahead of time. More than once I’ve seen a link for “delete this picture” - just clicking causes the data to go away (Flickr is guilty of this). While I sympathize with a page designer trying for a spartan look and feel, it is important to realize that a link is not a widget. This breaks the explore-ability of Web applications and exposes destructive operations to utilities and tools that pre-fetch data - links should cause no harm.
To really get the job done, Web designers should do the work to define the CSS necessary for a form to fit within their design. Keep links safe - just say no to ‘links via post’.
Pardon Mike, but I think you don’t give the user enough credit. If a *link* says, “Delete Picture” the user is cognizant enough to know what it means. Being consistent on interface design is nice and all, but personally, when I see a link I don’t first think, “Oh, this is a link and will not result in any destructive or altering behavior.”, especially if it is as descriptive as “Delete Picture” or “Add to Cart”.
I recognize the value in consistency, but I think we’re beyond the point on this one. If something is clickable and descriptive, the user should be fine.
Anonymous -
The whole point of using forms vs. links is to have non destructive actions be links and destructive ones be forms. That way when something like google’s crawler hits your site, it doesn’t delete a bunch of articles, or entries because it keeps following a very descriptive, but dangerous ‘Delete this Post’ link.
I tought a link is a click-to-visit URL.
The point of a URL being that it uniquely and completely identifies a resource. With a POST link, the URL itself is not enough anymore to locate the resource so it’s not a link anymore.
I also agree with only using GET for non-destructive operations, mainly requesting information. Remember, GET-requests may be cached and crawled.
I don’t see a problem with using a button in a form (styled to be visually indistinguishable from a link) to do a destructive POST-request. Userexpectation are a more flexible kind of convention then technical specifications.
Can someone kindly point to the asynchronicity (the big A in Ajax) here? It looks like pure synchronous Javascript to me.
Pardon Mike, but I think you don’t give the user enough credit. If a *link* says, “Delete Picture†the user is cognizant enough to know what it means. Being consistent on interface design is nice and all, but personally, when I see a link I don’t first think, “Oh, this is a link and will not result in any destructive or altering behavior.â€, especially if it is as descriptive as “Delete Picture†or “Add to Cartâ€.
http://www.astawerks.net
http://www.xtremedirectory.com
http://www.newgospel.net
I recognize the value in consistency, but I think we’re beyond the point on this one. If something is clickable and descriptive, the user should be fine.
To Anonymous who said that google can still crawl the POST link and thus perform the link’s actions…
The whole point of using AJAX and/or Javascript for POST links, is that the POST action is only registered if a real person actually CLICKS on the link, meaning performs the ONCLICK action. If google simply crawls the link it might go to the address, but it would do so using GET and thus will not do any damage if the server side code is set to ignore GET requests for that URL.
This is because internally a post link has an onclick action that does some javascript to actually perform the link’s action.
Using POST links is a great way to cut down on code and useless HTML. Why would you want an entire form just for a simple delete link? Or what about semi-destructive actions like ordering and changing a default?
You can keep your code clean and safe thanks to POST links.
It’s a great “invention”.