AJAX 101
Hats off to Sang Shin. This energetic Sun employee puts together high-quality online coursework around various Java-related topics, on his own time, and rightfully attracts a good crowd for each one. Check it out if you haven't already done so. The current course is around AJAX programming, and it's my pleasure to be sitting in.
Now, when I start learning a new technology, I look for the Hello World lesson - i.e., what's the least I have to do before I can actually get an A-to-Z out of it. And, if I can retrofit it quickly to my current project, all the better! Sang's first AJAX lesson does not disappoint; I've moved from AJAX-ignoramus to actually productizing my own customized validation routine in the last 1½ days. I count that as successful time spent, especially since AJAX-enabled behaviors in our product were deferred until "next year" - because we thought the effort would be prohibitive. Not!
You're invited to gain some immediate benefit from my learning curve, as I provide a series of "Cliff's Notes" type posts that summarize what I'm learning and how I'm applying it. What I'll present will start out with a certain naivety - since, frankly I still have a great deal to learn - but will likely evolve into something more sophisticated as I proceed through Sang's class. You are also, of course, invited to join me in this class - it's never too late with Sang's Java Passion courses, since they are self-paced.
AJAX is surprisingly easy to get going on - there's no downloads needed; you already have all the tools you need. This of course is true since we're looking at AJAX 101 - bare-metal vanilla no-frills and no-framework AJAX, which as Sang points out is not the way you'll (probably) end up using it, but is useful for instructional purposes. The moving parts, for this particular exercise, include some JavaScript, some JSP and a servlet - nothing new or exotic. So, while one of the many available AJAX frameworks may give us more power, there is plenty of value in first understanding things at a basic level.
Here's the problem space: our product, a web-based management application for iSNS, provides wizards that create various user-named objects in an iSNS space, and provides forms that support renaming these objects. As per the iSNS spec, all objects of a given type must be uniquely named. This validation is, of course, done on the server to maintain its database integrity; we are also motivated to do it on the client so that the user can be notified as soon as possible that the name he is choosing will not be acceptable.
Now, this is one of those types of validation that must in fact call back to the server to determine the acceptability, and this is where AJAX fits in nicely. So we'll set up a mechanism that calls back to the iSNS server to confirm the user-entered name is unique, and we'll spice it up a bit by also detecting an empty (zero-length) name, which likewise would not be acceptable. The payoff, of course, is that the user is notified of non-uniqueness or zero-lengthiness as she types, vs. having to submit the form and wait for a server response. It's asynchronous. But you knew that.
The AJAX-centric strategy to provide the validation is to (1) track user text input as it happens, (2) sending that input back to the server to check for duplicates or zero-length, (3) responding to the browser client with an assessment of the text input value, and finally (4) displaying a message and disabling submit-type buttons, or alternately removing the message and enabling the buttons, as needed.
I implement the strategy by lifting some of the code snippets presented in Sang's course materials, refactoring them into a generalized reusable set of JavaScript functions and one reusable servlet, and accessing these components from a JSP client. The JSP client will specify an event handler that tracks each character typed and invokes a JavaScript function to validate the input. This validate function is the on-ramp for clients, and is part of a collection that leverages the AJAX engine to provide something more of a "rich user experience". Finally, the servlet processes the GET generated from the validate function and does the validation, returning an XML-encoded response processed under the covers via the magic of AJAX. As usual, the servlet must not only be implemented, but it must be declared in the deployment descriptor.
BTW, there have been raised-eyebrow questions in class - and, before trying it, I had similar concerns myself - about round-trip performance when AJAX issues GETs with every character the user types. In this iSNS management webapp, with every character typed, the user-entered value goes
across the wire using RMI to connect to a JMX module,
which goes across a shared-memory interface, converting the query into XML
(using JAXB) going over JNI to a C-based server. The C-based server
looks things up in its database, replies back over JNI with XML, this
data then goes back over the RMI connection to the webapp which
converts the XML into Java objects (JAXB again). From there, the
determination is made about uniqueness (i.e. if the object is not null,
it is not unique).
Does this not sound like there'd be undesirable delay getting messages to the user? It did to me - but when I gave it a quick-and-dirty trial, the responsiveness was pretty much immediate at the user-facing level, even when the user
continues typing. Our design,
admittedly, has already been tuned for optimized round-trip
performance; we took explicit steps to make things lean-and-mean, otherwise the
responsiveness might not have been so good - but I wouldn't have known
for sure in either event until I tried it.
From this, as an aside, I would offer two thoughts: (1) don't solve performance
problems until you have one, and (2) don't assume you'll have a
performance problem until you do a quick proof-of-concept. I'll "soon" be posting articles about our iSNS webapp, and I'll point you to it so you can try the validation processing for yourself.
See you in class. I'll continue posting more about what I learn there, as I work my way through it.
