Section 6.2. The Context of the Web

6.2. The Context of the Web

So far, we've been considering universal principles of usability, nothing web-specific. Every principle, however, must be applied within some context. For every Rails application, the Web is part of that context. So let's step away from usability for a moment and consider the way the Web works.

6.2.1. HTTP

If you fire up an HTTP sniffing tool to see what is actually sent over the Internet when you browse the Web, you'd see the conversation between your browser and a web server. When you click a link, your browser sends a request like this:

GET /index.html HTTP/1.1 Host: Accept: */*

The first line is the request lineand the first word is the request method, in this case GET. After the method is the path of the URL being requested and the version of HTTP being used. Any following lines are request headers, giving the server additional information to help it fulfill the request.

HTTP methods are sometimes called verbs, because they carry out an action on some object. Just as in everyday speech, there are consequences to using the wrong verb in the wrong context (just imagine the potential consequences of uttering "you're fired" or "I thee wed" in the wrong contexts). HTTP methods have the same kind of potential to effect change, so they should be selected with care.

The most common HTTP method is GET. Any time you enter a URL in the navigation bar, click a standard link, or see an image embedded in a page, that data is requested with GET. According to the specification, GET requests should have no significant effect on the requested datait's defined to be a safe operation. In practice, the safety of GET enables all kinds of useful features, like caching and pre-fetching.

The property of safety is often confused with a related idea, idempotence. A method is said to be idempotent if performing it several times has the same result as performing it once. For example, the DELETE operation of HTTP is idempotent because deleting a resource twice is no different than deleting it once. GET is also specified to be idempotent.

The other familiar method is POST, most commonly used for submitting web forms. Whereas GET requests simply specify a URL, POST requests include a body as well, which can be any kind of data. The meaning of POST is essentially "process this," and as a result, POST is neither safe nor idempotent. That's why browsers must get confirmation before re-loading a web page that was accessed via POST. Otherwise, you might accidentally incur unintended obligations with the server.

Two other standard HTTP methods, PUT and DELETE, are often unsupported by browser and server software, but they are increasingly used as part of web services (see Table 6-1).

Table 6-1. HTTP methods and SQL equivalents
 Rough SQL equivalentIdempotentSafe









Using the appropriate HTTP method from Rails views is supported by the :method option available in the link and form helpers, as well as all of the Ajax helpers. Some examples:

<%= link_to "DELETE", some_url, :method => :delete %> <%= link_to_remote "PUT", :url => some_url, :method => :put %> <%= form_tag some_url, :method => :post %> <%= form_remote_tag :url => some_url, :method => :get %> <% form_for :person, :url => some_url, :html => { :method => :put } do |f| %> <% end %> <% remote_form_for :person, :url => some_url, :method => :put do |f| %> <% end %> <%= drop_receiving_element :droppable, :url => some_url, :method => :delete %> <%= sortable_element :list, :url => some_url, :method => :put %>

6.2.2. The Page

Taken to the extreme, Ajax radically upsets the way the Web works by undermining the concept of the page as the fundamental unit of the Web. But what's so special about the page anyway? At first blush, it seems like an awfully archaic metaphor for describing one of the defining technologies of our time. After all, real-world paper pages are static, fragile, fixed. The Web needn't have any of those constraints, and yet it's the dominant metaphor. Why?

Although it seems trivial in retrospect, it's really a testament to the genius of Tim Berners-Lee that he provided the concept of the page. With it, he unified several distinct concepts into one. The most obvious one is what you see: the visual representation of some data in a window. Second, pages have a one-to-one correspondence with an addressmeaning you can always see where you are, and you can always jump directly somewhere else. Third, pages provide the unit of navigationwith every click of a link, you transition from one page to the next. And finally, pages can (in the simple cases, anyway) correspond directly to a static file on a web server. Prior to the Web, other information services on the Internet had some of the same concepts, but they weren't unified by an overarching metaphor like the page. Could it be that conceptual unification is what drove the success of the Web?

So we should think carefully before doing away with pages. What does Ajax bring to the table? Is it worth it? What are the advantages of splitting the atomic unit of the Web?

The answer is complex, but it can be summed up in one word: applications. The original vision of the Web emphasized content as document. It quickly evolved into something more interactive, and, before long, the Web was being used to replace some desktop software. As the Web continued to supplant traditional software, the page model inhibits certain rich interfaces that are taken for granted in that traditional software.

Ajax provides some measure of release for the tension between the Web and desktop applications. At the risk of sounding Buddhist, the challenge of Ajax development is a balancing act between your site's web nature and its application nature. Of course, desktop software development provides decades of experience building interfaces for systems that permit rich interaction. Many of those lessons are directly transferable to Ajax design. Nevertheless, it's a mistake to assume that Ajaxified web applications should exactly mimic desktop software. Modern web applications are fundamentally different from both traditional desktop software and traditional web sites. Good Ajax design will recognize that and embrace the unique nature of the Web, as well as the best interaction strategies from desktop software.

Ajax on Rails
Ajax on Rails
ISBN: 0596527446
EAN: 2147483647
Year: 2006
Pages: 103
Authors: Scott Raymond

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: