The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
GWA lesson

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Agnieszka Figiel

Posts: 50
Nickname: agnessa
Registered: Feb, 2006

Agnieszka Figiel is a Ruby on Rails programmer & coach
GWA lesson Posted: May 6, 2006 10:25 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Agnieszka Figiel.
Original Post: GWA lesson
Feed Title: agnessa's blog
Feed URL: http://blog.agnessa.eu/xml/rss/feed.xml
Feed Description: ruby and rails impressions from a beginner developer
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Agnieszka Figiel
Latest Posts From agnessa's blog

Advertisement

It’s been about a year since the Google Web Accellerator caused panic in the web development world. As an extreme beginner at that time I regarded it (along with many other equally ignorant people I guess :) ) as Google’s malicious follow-my-rules campaign against poor unconscious developers. Probably as many others I applied the rails anti-GWA hack to my first app with a feeling of great satisfaction and relief :)

Luckily with time I realized it was actually my mistake. I recently found a thread on the Daily WTF, mocking someone’s ignorance in the matter, which makes me think others have also grown :)

Many people still use GET links for state changing actions and many newbies are completely unaware of the fact that they shouldn’t be. I think the key to this is because people learn mostly by example, which tends to be bad. So it’s nice to actually see a good example in the place many people start learning – in the rails scaffolded code. The usual “Show”, “Edit” and “Destroy” links code looks as follows:

<td><%= link_to 'Show', :action => 'show', :id => account %></td> <td><%= link_to 'Edit', :action => 'edit', :id => account %></td> <td><%= link_to 'Destroy', { :action => 'destroy', :id => account }, :confirm => 'Are you sure?', :post => true %></td>

And the generated html looks like this:

<td><a href="/account/show/1">Show</a></td> <td><a href="/account/edit/1">Edit</a></td> <td><a href="/account/destroy/1" onclick="if (confirm('Are you sure?')) { var f = document.createElement('form'); this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href; f.submit(); };return false;">Destroy</a></td>

This makes the “Destroy” link safe without turning it into a button and sets a good example for a beginner who analyses the code. Still, I guess the button approach (like button_to ) appeals more to me, for one because I’d rather make something ugly than resort to javascript :) But more importantly because the button – link distinction makes it more obvious for the user if an action is destructive or not. Many people tend to think that the only effect of clicking links should be to show something. And buttons do not have to be that ugly as by default with a bit of style tweaking :)

rfc2616:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Read: GWA lesson

Topic: 头å' Previous Topic   Next Topic Topic: Null Object Pattern

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use