分类： 系统运维
2009-04-04 19:11:47
I have read a book entitled “The Art of Rails by Edward Benson” Published by Wiley Publishing, Inc. . Its a must read book if you want to accelerate your knowledge in rails to the next level. In a certain chapter of this book covers about the five different styles of applying AJAX to enhance your web application.
These styles are by no means official standards — the terms are creations of this book — so there are no doubt more ways to organize your code. These five appear to be the predominant ones, however, so provide a good starting point for just about any application type you want to pursue.
Each of these five styles is a different way to approach AJAX, and the code you write for each will have a different look and feel to it. Which one to use is your choice, and mixing more than one style in your application is okay, too. The goal of this chapter isn’t to box you into a single way of coding but rather to make you more conscious about design issues you might otherwise have overlooked.
The proxy style is how you might think of AJAX when you first hear the acronym’s description. With this strategy, the application still takes place across multiple web pages, and the server remains a big part of the decision making. AJAX is used as a back channel for data connections between rich JavaScript elements on the page and functionality and data hosted on the server.
The proxy style is essentially a Model-by-Wire style of coding. Just as your model objects are rich Ruby representations that front for the data stored in your database, proxy-style AJAX uses rich JavaScript objects that front for the capabilities provided by the remote server. Certain JavaScript-enabled elements on the page contain client-side logic relevant to their display and user interaction. In this way, the client pages are rich, JavaScript-enabled environments capable of taking care of themselves from a display point of view.
A good example of this style is the YUI DataTable widget. This widget acts as an embedded spreadsheet, complete with cell renderers, validation, and sortable columns. The widget can be initialized, configured, and added to the page completely through JavaScript. Provided a URL, it will contact that endpoint expecting XML data in return that it uses to populate its rows and columns.
On the extreme end of the proxy style is the DWR (DirectWeb Remoting) framework. Like a hand-written version of GWT (the Google Web Toolkit), DWR couples full-blown JavaScript service proxies for remote Java services. JavaScript callers on the client side can use the proxy as if it were a regular JavaScript object, while behind the scenes it enacts each method call by passing it to the server over an AJAX connection.
Partial-style AJAX is a completely different way of applying AJAX made popular by the Ajax.Updater object in Prototype and the Rails macros that use it. In this style of coding, AJAX is used to transfer bits of preformed HTML, rather than data, back and forth. These HTML fragments are then inserted into some location on the page, usually depending on the status of the response (success or failure).
Partial-style AJAX is attractive because of its intuitiveness and similarity to the way in which web applications worked in the pre-AJAX days. In those days, you clicked a link and received a new page. With partial-style AJAX, you click a link and receive a new page fragment. Think of the ‘‘Next 20 Items’’ link in an AJAX-powered storefront, the ‘‘Expand Thread’’ link on a discussion board with nested comments, or the ‘‘Add Item’’ button on a Todo list application. All these actions are circumstances in which the simplest way to implement them is to connect to a URL that causes the desired action to happen and then have the server respond with only the HTML necessary to furnish the response, which replaces or adds to HTML already on the page.
Puppet-style AJAX is the other form popular with Rails developers, primarily because of the RJS package that ships with Rails. From the perspective of the client code, this style looks a lot like the partial style. The difference is in the contents of the data that comes back from the server. In partial-style AJAX, the response from the server is HTML fragments. In puppet-style AJAX, the response is JavaScript to be executed on receipt. In this way, the client acts like a marionette, sending AJAX requests to its puppeteer, the server, and executing its instructions in response.
This manner of writing AJAX is unique because it creates an implied dependency between the client page and the server application: The page can’t function without instruction from the server, and the server can’t send instructions without knowledge of the page. This dependency is different from most of the other styles of AJAX, in which the page operates more or less as a stand-alone and self-managing unit after it leaves the server. Even when using AJAX, the data provided by the response is under the control of the JavaScript code in the client. Not so with the puppeteer approach, because the page blindly executes whatever JavaScript is sent back to it. This dependency has both benefits and downsides.
The compiled-to-web style of AJAX is a bit of an anti-style because it is defined by the very lack of developer control over how JavaScript is written and how AJAX is used. This is the one style that can work with only specific frameworks, because the framework must provide some abstraction other than the web to the developer and must compile code using that abstraction down into web pages and server calls. Even RJS, which can be thought of as a Ruby-to-JavaScript compiler, doesn’t qualify for this level of abstraction away from the web because it is only a direct replacement for JavaScript, not the entire web architecture.
The primary example of this type of coding is GWT, the Google Web Toolkit. GWT allows developers to write web applications using Java and a Swing-like library. Provided that certain conventions are followed, the resulting application is compiled down to a server-side component plus the HTML, CSS, and JavaScript needed to fuel the client-half of the application.
Compiled-to-web frameworks such as GWT are a good fit for people who prefer to avoid AJAX and the web world of languages in general and who would rather take advantage of the language environment and tools available at some higher level. For GWT, this means that developers get to write web applications as though they were Java applications, providing all the benefits of Java debugging and Java IDEs for free.
The last style of AJAX development is the most extreme, even more so than the compiled-to-web approach. In-place web applications are essentially rich-client applications that happen to be deployed as a bundle of HTML, JavaScript, and CSS. They exist on the web, but only because that is how they are deployed. Local storage is made possible through the use of a proprietary run-time environment (such as AIR), a browser plug-in (such as Google Gears), or native browser support (such as Apple’s WebKit browser engine), and that storage is used to persist much of the user’s data for access when offline.
When the user is connected to the web, AJAX connections are used to synchronize application data with the master copy on the application server. The web site might even operate offline, but additional features are available when web connectivity is present. The design attempts to keep AJAX requests to a minimum, though, and to provide just these extras. The majority of interactions and state modifications on the page are handled locally via JavaScript so that the page can continue to function at some level without an Internet connection present.
This type of development is appropriate for developers who want to go after either the traditionally non-web market or court users who are concerned about poor or only periodic network connectivity. An example of the latter case is Apple’s iPhone, released in 2007 with the web as its development platform but whose slow and sometimes unavailable wireless network interfered with making this platform a true killer application. Developers quickly found ways to embed data locally using strategies ranging from cookies and bookmarklets to data URLs that enabled small web applications to be loaded on the phone in such a way that they worked both on- and offline.
