The Year of AJAX, Take Four: Part II

Last week, I talked about the ADF Faces Rich Client components included in ADF 11g, the rich capabilities they offer, and the fact that I still don’t think they use AJAX to its full potential. I mentioned some examples of how I’d like to see these components evolve in 12g.

Of course, with JDeveloper 11g still in technical previews, JDeveloper 12g is not on the horizon yet–I don’t know if it’s even in development–so from the perspective of a developer out in the field, any discussion of how these components might be enhanced for 12g is still pretty pie-in-the-sky. What can developers do in the mean time?

Realize That What You’re Getting Is Still State-of-the-Art

The fact is, you’re not going to see a whole lot of components anywhere that take full advantage of the power of asynchronous Javascript calls. In case you didn’t hear it the first 17 times I said it (last week), the ADF Faces Rich Client components are really cool. Using them is a very rich, desktop-like experience, and over a low-latency connection you’re unlikely to notice much interruption at all. Please don’t let my criticisms here take away from the very real admiration that is due these components.

Use Lazy and Immediate Content Delivery Appropriately

Lazy loading is great–when it’s appropriate. But remember that, at a certain point, latency concerns overrun bandwidth concerns. It’s a very good idea to load a 5Mb table a little at a time, because loading it all at once not only takes up significant server resources, it takes a noticeable amount of time to get down the pipe–even a modern broadband pipe. But a 20kb table? Unless your customers are using 300-baud modems, they’re not going to notice an extra 20k of initial page load. They’re going to feel far more annoyed at the latency involved in a bunch of server round-trips to get the table bit-by-bit. Use immediate content delivery for any reasonably small table, tree, or popup.

Consider a Javascript-Only Solution

By “Javascript-only,” I don’t mean that you should implement critical business rules purely in Javascript, with no backup on the server. That would be a very, very bad idea. I simply mean using the server only as a backup, to be consulted after form submission, and handling as much of the response to user action as possible in pure Javascript, with no partial requests. This involves loading all the data you might possibly need for page changes into a Javascript object that gets downloaded with the original page, so it’s obviously not for all cases (if your validation rule requires that a parametrized query against a million-row table return some value, this is not a good option for you).

However, if your case is not like that, doing direct Javascript manipulation of ADF Faces components is a lot easier than it once was, because ADF Rich Client contains an extensive Javascript API for working with client-side components. The API is effectively undocumented in the current Technical Preview (the Javadoc pages are there, but they’re all stubs, so far as I can tell), but presumably that will change by the official release. In the mean time, Frank Nimphius has a nice, though at this point still small, collection of “JavaScript Programming Gems.”

Consider Making Your Own Asynchronous Calls

This is harder than it sounds. Not because making asynchronous Javascript calls is so difficult (it’s not), but because integrating such calls into the rest of your application isn’t going to be trivial. You have two choices, each with some problems.

If you can figure out what Javascript-and-XML calls the client-side is making to the server, you can make your own client listeners that do the same thing, except asynchronously. But the specifics of messaging between the client and the server are not documented, and they are, I imagine, quite complex. It would require quite a bit of research; you’d have to carefully study the Javascript generated by ADF Faces by default, and adapt that.

Alternatively, you could try to make asynchronous calls to a web service based on your business services. That’s easy when, say, you’re querying lookup data, but for transactional data, ensuring consistency between the what is seen by ADF Faces and what is accessed from the web service will take some work.

For example, the default way that JDeveloper constructs a web service for an application module doesn’t give you any control over which application module instance you get–the assumption is that web services are used statelessly, and not just in the “stateless with managed state” sense that characterizes the application module pool. Which means that you’re going to have to build your own web-service that accepts, say, a SessionCookie and then invokes whatever call you’ve made on a matching application module instance. This means you’re not going to be able to use JDeveloper’s automated “Publish as J2EE Web Service” option for your application module.

What you’ll have to do instead is to create a simple Java class that acts as an application module client, and build a web service around that. For example, suppose you have an application module MyModule, and want to call an application module method with a signature

public Boolean makeDataChange(Number newVal)

After exporting this method to the interface, you’re going to have to create a class with a wrapper method something like this:

public Boolean makeDataChange(Number newVal, SessionCookie cookie) {
    MyModule module = (MyModule) cookie.getApplicationModule();
    return module.makeDataChange(newVal);
}

And expose that as a web service (SessionCookie extends Serializable, so that’s not a huge problem).

These three options are in ascending order of gun size. Really, I think that if you use immediate and lazy content delivery appropriately, and maybe consider learning the Javascript API well enough to do some of the less data-intensive operations on the client side, you can probably hold out for ADF Faces components with built-in asynchronous communication for the rest, without worrying about implementing your own asynchronous solution. It’s really just fine for the vast majority of applications, and you’ll look just as whiz-bang as anyone else on the web.

Leave a Reply

Your email address will not be published. Required fields are marked *