It’s only recently that we at the office were able to see what AJAX has in store for our web applications. Thanks to DWR, most of the crazy code behind implementing AJAX is relegated to its packages instead of us manually doing it. Of course, that doesn’t mean that learning how DWR operates is unimportant ― rather, it’s because of the nature of software development that occurs here at the bank that takes precedence.

Most of the time, systems that get developed here have short programming times. Like what I learned during our ComSci prof’s lecture a few years back, it’s R.A.D.: Rapid Application Development. The documentation doesn’t even see print immediately (if at all), because the deliverable (the actual system) has to be deployed in a few months (or weeks) time.

Similar to most math problems that get solved during exams, the e-solutions do not come out entirely clean. Sometimes, code elegance has to suffer (inevitably) just so the system will make it to deployment day on time. Simple tasks like two <select> dropdowns, with the second one having values dependent on the selected in the first dropdown, becomes an entirely sluggish process because the page has to reload first before the second dropdown even gets to have values (i.e., after selecting from the first dropdown, page submits to get second dropdown’s values). Code refactoring is thrown at the back burner for the usual reasoning that if it ain’t broke, don’t fix it. Thus, the quality of the code eventually becomes an electronic hodge-podge.

If only we knew how to do it the AJAX way in the first place.

AJAX, as I have read so many times in the past, has been a buzzword for those dealing with so-called Web 2.0. There’s no doubt our web apps still have a looooong way to go before we even reach that phase. But that doesn’t mean we shouldn’t take advantage of AJAX whenever we are presented with problems on how to go about certain page functionality.

For one, simple page reloads can be remedied with non-reloading until the page form is complete; those form elements that require values dependent on selected values of other fields should rely on AJAX to get the job done. Informational messages that convey something about some inputted data (such as whether a certain account number is available for creation or not) shouldn’t even require a separate pop-up window just to let the user know. AJAX and dynamic HTML can already do it to improve the speed and behavior of the application.

And this is where DWR comes in. For the longest time I was clueless as to how AJAX can be implemented under the BEA’s (now Oracle’s) WebLogic platform. Simply put, how can I do AJAX in Java? Countless times have I encountered sites that discuss and lecture about AJAX via PHP. I was having difficulty connecting the two dots together. Thank God for DWR, I would not have to worry about that anymore. I just code away the Java class that connects to the database backend, and then code the frontend JSP. It would be that simple, with a few bits of Javascript thrown in between to make the connection work. But of course, it took me great lengths to understand DWR first in their website, especially that the concept of AJAX was very new to me at that time.

Moving forward, I just hope we’ll be able to utilize this technology to improve our systems. It would be such a shame if we couldn’t. This is the best thing that has happened to Javascript in a long time.