 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|||||||||
| |||||||||||
|
|||||||||||
| |||||||||||
|
|||||||||||
|
AJAX, my boy, AJAX.
05.05.06 7:00 PM  By dplass TopCoder Member When I first read the title to the Next Generation Development Round Table, I immediately thought of one of my favorite TV shows. I thought it would refer to such development processes as XP, SOA or some other heavily-hyped process. After reading the executive summary, thought, I saw that it promised to describe the effect of new user interface paradigms on development. However, I still had no idea what the actual technology or paradigms were. User interfaces have evolved greatly since the old punch-card days. We moved from punch-cards, being handled by the high priesthood, to command line, to mouse-and-menu GUIs, and finally Web. What? "Isn't web just a model on top of the GUI?" I asked the presenter, Andy Lamora (a TopCoder Project Manager.) The answer was yes, it is a model on top of GUI, but it was actually a step backwards (indeed, even all the way back to the punch-card days.) You give a web application input, and you have to wait (sometimes multiple seconds) for its output. He showed a cute graphic with the analogy that we used to give punch cards to the mainframe and get paper tape or other output in response some hours later. Along the way, web application (middle-layer) architectures evolved, but the front end still suffered from the need for users to download a run-time separate from the browser (either applets, Flash, or Java Web Start). So what can be done to improve this situation, to change the paradigm for web applications? Like the family friend in The Graduate who said "Plastics, my boy, plastics", the answer here was "AJAX, my boy, AJAX". I won't go into the details of AJAX here, but I will outline some of the implications that Andy talked about. First of all, instead of loading a humongous application (equivalent to a full-page refresh), you can load just small parts at a time (only the part of the page you need.) Since this is in the background, you can dynamically offer new options in controls, or dynamically change the behavior or appearance of controls to help guide the user to do what they want to do. (Andy advised that what those controls should be screaming at their users is "Grab me here, touch me there." Hey, what happens in Vegas, stays in Vegas, right?) Secondly, there is now a blurred boundary between the front and back ends. Who codes the JavaScript? The designers? The middle-ware developers? Is AJAX part of the UI? Is it programming? Is it Architecture? The answer is that you have to apply the same good software design and development practices to an AJAX-based application as you would to any other web- or non-web-based application. As a result, "Programmers program, designers design," as one of Andy's slides pointed out. Model-view-controller designs should still reign supreme, as they did for client-server and Plain-old-web-apps (POWAs -- hey, I coined a phrase!) You should use Design Patterns, most notably the Command Pattern, which becomes critically important if you want to implement an entire application within the browser. A great example is the "Undo" command. Instead of refreshing the whole page, you could implement the Command Pattern in JavaScript, only undoing the sections of the page that need to be reverted. Also, the Observer Pattern comes into play, because of the Asynchronous aspect of AJAX. You use callbacks, which implement the Observer Pattern, to make sure the right data goes to the right controls at the right times. Similar to the CBSE approach, you should build libraries of JavaScript files instead of using an ad hoc method of putting some in the <head> and some in .js files. Andy then pointed out the benefits and drawbacks of XMLHttpRequest versus IFrames. Right now, XMLHTTPRequest does not have easy, standard universal support in all browsers. Internet Explorer 7 will do away with the need to have ActiveX enabled; the default setting is that ActiveX is disabled in IE 6, causing many users to not be able to take advantage of AJAX. (The irony is that Microsoft invented the XMLHttpRequest object, which is the basis for all AJAX communications.) Security is an issue for all AJAX applications, not on the browser side, but also on the server side. You have either control all security on the server (e.g., single sign on), or somehow open up multiple connections from the browser, which is clumsy. This may be ameliorated (take that, davidyang!) by a Service Oriented Architecture approach, whereby you can more easily manage the security in the Service container. Finally we closed up with describing the acceptance and future of AJAX. Already, JSF can support AJAX, and Microsoft has released its Atlas product. Ruby on Rails supports it out of the box. We have all seen Google Maps, one of the first widely-used AJAX applications, GMail, and Flikr, not to mention Google Suggest (which has been around almost since the word AJAX was coined.) In the future, SOA will interact with AJAX applications as I mentioned above, and ASP (Application Service Providers) may benefit after years of decline, because users will once again be able to run "full-fledged" applications within their browser. Among the questions posed by the mostly-non-TopCoder-member audience (save myself, Pops and ThinMan), two stood out that may be of concern, especially if TopCoder is to get into the AJAX component business:
All this was going on at the same time as the Algorithm Finals in the other room. When I got back, tomek had already submitted his 250 point problem for over 245 points. Wow! Also, the CDDC Final Development appeals phase was almost done; argolite was done fixing his configuration so he could finally re-run his Accuracy tests and resolve the last of the appeals. I know we're all anxiously waiting the results (also so I can blog them!) AJAXly yours, --DP |
    |