Friday, October 28th, 2005

Ruby on Rails uses Ajax to simulate POST links

Category: Ruby

<p>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.

Related Content:

  • Hot skills: Ruby on Rails 2.0
    Rails is not the only framework for Ruby, and Ruby is not the only language which uses Rails. Rails has also been ported to Javascript by a team at...
  • Choosing an Ajax framework
    Your customers won't have to fear Ajax if they have the right tools to work with. Help them determine which Ajax-specific framework, library or...
  • Web 2.0 resume app leverages SOA, Rails, cloud computing
    Startup founded by former webMethods execs provides online multi-media resumes using Ajax applications built with Ruby on Rails and running in the...
  • Ajax Learning Guide
    Are you a Web developer? The time has come to rethink your entire approach to developing Web applications. Find out about the Ajax approach...
  • Find Ajax security flaws using tests
    Ajax security problems can be found by doing manual tests. What should you look for in order to prevent an attack? Andres Andreu provides some advice...

Posted by Dion Almaer at 2:45 am
8 Comments

+++--
3.6 rating from 27 votes

8 Comments »

Comments feed

Yes, but you can also use: form { margin: 0; } in your css to reduce the havok a form tag can do on your layout.

Comment by David — October 28, 2005

(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’.

Comment by Mike D — November 17, 2005

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.

Comment by Anonymous — December 20, 2005

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.

Comment by N Dev — March 16, 2006

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.

Comment by mathias — May 26, 2006

Can someone kindly point to the asynchronicity (the big A in Ajax) here? It looks like pure synchronous Javascript to me.

Comment by loqi — April 2, 2007

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.

Comment by jbrock — August 26, 2007

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”.

Comment by Dmitri — October 25, 2007

Leave a comment

You must be logged in to post a comment.