464CHAPTER 11

The enhanced Ajax web portal

handleError: function(request) { if ( this.options.messageSpanId )

document.getElementById (this.options.messageSpanId).innerHTML =

"Oops! Server error. Please try again later.";

},

This method checks for the existence of the messageSpanId configuration property and, if it exists, uses it as the element to place an “Oops!” message onto the UI. The actual text of the message that’s presented is something that could also be parameterized with the options object. This is an exercise left to the reader.

With that, our portal component refactoring session has come to a close. We’ve created a deceptively simple mechanism for providing Ajax portal management. Now let’s take a few moments to review the focus of our refactoring and recap what we’ve accomplished.

11.6.5Refactoring debrief

In a couple of ways, the development of this component is quite different than the other component examples in this book. First, the portal component is a more coarse-grained component for providing an Ajax-based portal capability. A third-party developer is unlikely to want to drop a portal system into the corner of his page! Second, it uses a technique for handling Ajax responses as JavaScript code. Our refactoring of this component focused on ways to isolate change points. This was illustrated in several ways:

■We provided a clean way to adapt the AjaxWindows.js library.

■We isolated string literals as pseudo-constants.

■We wrote a generic method for issuing commands.

■We isolated via a method the concept of running an Ajax response script.

11.7Summary

The portal can be one of the most powerful tools a company has. The company can set up business logic to allow users to see only the information that pertains to them. Portals also allows users to customize the look and feel of the window to fit their needs in order to increase their performance since the page is laid out exactly as they want it to be.

By using Ajax in the portal, we can keep all of the functionality in one area without having to send the server to multiple pages. There is no more worrying about what the back button is going to do when the user logs out. There will be no

Summary 465

page history, since we never left the page. We talked about the drawbacks of navigating away from the page, but we were able to solve the problem by using Ajax to perform a request to the server.

We also sent requests back to the server without the user knowing that data was being saved. By triggering Ajax with event handlers, we are able to save data quickly without disrupting the user’s interaction. A portal that uses Ajax introduces a new level of performance in a rich user interface.

In the final section of this chapter, we looked at refactoring the portal code. In previous sections, we have focused on creating a reusable component that can be dropped in to an existing page. In this case, that isn’t appropriate, as the portal is the shell within which other components will reside. Our emphasis in these refactorings has been on increasing the maintainability of the code by isolating String constants, creating some generic methods, and separating the third-party library from our project code in a cleaner way.

In this chapter, we’ve generated simple XML responses from the server and decoded them manually using JavaScript. In the next chapter, we’ll look at an alternative approach: using XSLT stylesheets on the client to transform abstract XML directly into HTML markup.