PART II
Chapter 9: Site and Application Architecture with Ajax 477
client-side JavaScript; server programming languages and frameworks like PHP, JSP, .NET;
and many others all mixed up in a big stew we call a Web application. And don’t forget the
database that likely stores the information that populates this monstrosity—that must be
acknowledged as well. Developers would likely want to eliminate some of these parts and
stick with things they know. If they know Java, then it would make sense to try to author
completely in Java. If an Ajax-aware development framework can hide the JavaScript issues
from us, even better. This isn’t language specific to Java; the same thinking could apply to
.NET programmers, Ruby programmers, PHP programmers, and just about anyone else
who wants to simply stay away from that which they may not understand, trivialize or
simply dislike: JavaScript.
Tightly coupled Ajax development environments that generate JavaScript or leverage
and insert existing libraries automatically give us the illusion that there are less moving
parts, but the situation is the same. What’s worse is now we lack control and find ourselves
only as good as the framework we use, with no way to easily fix client-side issues without
getting into the plumbing of the development system and overriding what it does. When
we start to get into that depth, it begs the question of why we bothered to do it this way.
Tight coupling also doesn’t acknowledge the separation of concerns that is the reality of
Web development. The front-end people have a roll to fill. Generally, the back-end folks
generating the code don’t do such a great job on the user interface, or the tool makes our
Web application look very similar to our competitors. The front-end people design a change,
and it is difficult to employ because of the way the tightly coupled system works. Even if the
new look can be integrated, often we can’t easily let the front-end people do the work.
We honestly believe that you need to get into the JavaScript to effectively use Ajax to its
fullest potential, but regardless of our strong opinion, let’s take a tour of how various
systems approach a more tightly coupled view of the Ajax development.Exploring Tightly Coupled Architecture Approaches
As an example of a tightly coupled architecture, we look at Hello World from Chapter 1,
developed using the much hyped (and rightfully so) Ruby on Rails (www.rubyonrails.org)
architecture. Here we see the file helloworld.rhtml.<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<%= javascript_include_tag "prototype" %>
<title>Hello Ajax World Rails Style</title>
</head>
<body>
<%= link_to_remote "Say Hello" ,
:update => "responseOutput",
:url => { :action=> "sayhello" } %>
<br /><br />
<div id="responseOutput"> </div></body>
</html>