AJAX In Action [221]
Call to load windows
document.getElementById('username').focus();
}
function login() {
myPortal.login( document.getElementById('username').value,
document.getElementById('password').value );
}
In this usage semantic, createPortal(), which should get called once the page loads, creates an instance of the portal component. The first argument is the base URL for the portal’s server-side application b, and the second provides optional parameters used to customize it for a particular context c. In this case, we tell it the ID of the DOM element into which status messages should be written and the name of the request parameter that will denote which action to execute. Once created, an API on the portal named loadPage is called. This loads the page’s portal windows if there is already a user login present in the server session d. If nobody is logged in, this server will return an empty script, leaving only the login form on the screen.
The login() function is just a utility function in the page that calls the login() method of our portal component, passing the username and password values as arguments. Given this contract, the login button’s onclick handler now calls the page’s login() method, as shown here:
11.6.1 Defining the constructor
Now that you have a basic understanding of how the component will be used from the perspective of the page, let’s implement the logic, starting with the constructor:
function Portal( baseUrl, options ) {
this.baseUrl = baseUrl;
this.options = options;
this.initDocumentMouseHandler();
The constructor takes the URL of the Ajax portal management on the server as its first argument and an options object for configuration as the second. In our Licensed to jonathan zheng 456 CHAPTER 11 The enhanced Ajax web portal earlier development of the script, recall that we had a servlet filter and two servlets perform the back-end processing. Throughout the rest of this example, we’ll assume a single servlet or resource, portalManager, which intercepts all requests to the portal back-end, as configured in listing 11.13. If we wanted to configure the portal against a back-end that didn’t use a single request dispatcher, we could simply pass different arguments to the constructor, for example: myPortal = new Portal( 'data', { messageSpanId: 'spanProcessing', urlSuffix: '.php' } ); This will pass a base URL of “data” and, because no actionParam is defined in the options array, append the command to the URL path, with the suffix .php, resulting in a URL such as data/login.php. We’ve given ourselves all the flexibility we’ll need here. We’ll see how the options are turned into URLs in section 11.6.3. For now, let’s move on to the next task. The final line of the constructor introduces the issue of adapting the AjaxWindows.js library. 11.6.2 Adapting the AjaxWindows.js library Recall that the implementation of this portal used an external library called AjaxWindows.js for creating the individual portal windows and managing their size and position on the screen. One of the things we had to do was to adapt the library to send Ajax requests to the portal manager for saving the settings on the mouseup event. This was the hook we needed; all move and resize operations are theoretically terminated by a mouseup event. The way we performed the adaptation in round one was to make a copy of the AjaxWindows.js library code and change the piece of code that puts a mouseup handler on the document. If we think of the AjaxWindow.js library as a third-party library, the drawback to this approach is evident. We’ve branched a third-party library codebase, that is, modified the source code and behavior of the library in such a way that it’s no longer compatible with the version maintained by its original author. If the library changes, we have to merge in our changes with every new version we upgrade to. We haven’t done a good job of isolating this change point and making it as painless as possible. Let’s consider a