News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

There WILL be a JavaOne this year
JavaOne will happen in 2010, as a co-located event with Oracle's OpenWorld, on Sept. 19-23 in San Francisco.
01/27/2010 01:02 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

The Next Big Thing




February 1, 2006 — 
Unless you’ve been living under a rock, you’re probably aware that AJAX seems to be the next big thing. AJAX is not really a technology at all, however—it’s a technique. I’ve been using it in my most recent project, and here are my experiences.

The basic premise of AJAX is to move all the presentation-layer code from the server to the browser. The server presents two types of information to the browser: generic Web pages that contain no data and data streams that contain the information displayed on these pages. That is, instead of creating custom Web pages, the server produces custom data sets for stock Web pages. The data can be sent using XML, but in the application that I’m building, I’ve found that it’s not worth the trouble. I’m just sending comma-separated lists.

At the heart of AJAX is a single JavaScript function call: xmlHttpRequest(). In spite of the name, this is not an XML-related function at all. It simply issues an HTTP GET or POST, and returns the data returned by the browser. On the server side, these requests are handled by standard servlets running under Tomcat. (The Web pages that contain the xmlHttpRequest call are served by Apache, and there’s no need to connect Apache and Tomcat with ModJK since Tomcat isn’t actually serving Web pages—it’s just creating data streams. Tomcat and Apache can be running on separate machines.)

Since it’s JavaScript, you can’t just call xmlHttpRequest, though. The function’s behavior is browser-dependent. Fortunately, you can create a function that wraps the hideous garbage needed to make the function call work.

I found a few useful descriptions of how to make xmlHttpRequest actually work at developer.apple.com/internet/webcontent/xmlhttpreq.html,jibbering.com/2002/4/httprequest.html, www.omnytex.com/articles/xhrstruts (which describe how to use an xmlHttpRequest with Struts), and www.xml.com/lpt/a/2005/02/09/xml-http-request.html. There’s also a really useful set of detailed AJAX examples at www.clearnova.com/ajax.

In my application, all I was doing with Ajax was flowing different chunks of HTML into a <div> element based on user input. Since this is pretty basic JavaScript programming, which I already knew how to do, just figuring out how to make the xmlHttpRequest call was all that I needed. The servlets that responded to the request were trivial to write.

The hype behind AJAX is that it provides you with a way to build browser-hosted user interfaces that are as responsive as client-side user interfaces. The responsiveness of the UI is really all just JavaScript programming, however. Massive amounts of it. AJAX gives you nothing but a way to update part of a Web page without reserving the whole thing. You can trap a user’s characters as they’re typed, for example, send the characters to the server as part of an HTTP request, and print error messages (or reject the input) based on the response. This is an awful lot of work to do on a one-character-at-a-time basis, however, which brings us to the dark underbelly of AJAX: It’s often not a particularly efficient use of the HTTP protocol, and getting things to work typically involves mondo JavaScript programming.

I, personally, think that the people who invented JavaScript and then decided to implement it differently in every browser are going to end up in the eighth circle of Hell along with the other “Sowers of Discord and Schism.” It certainly feels like hell to program the stuff. FireFox, at least, has an acceptable source-level debugger for JavaScript (www.mozilla.org/projects/venkman), but the odds of your FireFox code porting to Explorer, which has no debugging support at all, are small. At least it’s a start, though.

If you don’t know it already, you’ll also have to learn JavaScript at a nontrivial level to do any AJAX programming. There are, of course, a billion intro-to-JavaScript books and online tutorials. (There’s a reasonably good tutorial with a great online reference at www.w3schools.com/js/default.asp.) JavaScript books that focus on AJAX are just now appearing. I’ll report on them as they come across my desk.

The real issue with AJAX, at least for the moment, is that it’s just too hard to do. I really don’t want to become a JavaScript programmer. For the technology to really become viable, then, a lot of work needs to be done. In particular, we need a Java framework that provides a stock set of platform-independent JavaScript controls that we can just cut and paste into the HTML, and on the other side, we need a standardized UI framework that hides all the servlet programming from our applications. Let’s hope that, over time, something reasonable will emerge.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/29101
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading