AJAX In Action [220]
The concept of an Ajax-based portal client that interacts with a server-side portal
“manager” is, as you’ve seen, a compelling notion. In our refactoring of this chapter’s client-side code, let’s consider our component as an entity that serves as the arbitrator of portal commands sent to the portal manager on the server. Throughout this refactoring discussion, let’s make it our goal to isolate the pieces of code that might change over time and facilitate those changes as easily as possible. Since the portal is a much coarser-grained component and something that will more or less take over the real estate of our page, we won’t be so stringent with the requirement of not interrupting the HTML as we have in the previous two refactoring examples.
But, before discussing the client-side semantic, let’s first stop and contemplate the contract with the server. Our previous server-side implementation was written in Java, so we had a servlet filter perform the authentication functionality: one servlet to return the window configurations, and another servlet to save window configurations. Similarly, for adding new windows and deleting the current ones, we would provide further standalone servlets. In a Java web application, the servlets Licensed to jonathan zheng 454 CHAPTER 11 The enhanced Ajax web portal can be mapped to URLs in a very flexible fashion, defined in the web.xml file of the web archive (.war) file. For example, our SelectServlet, which returned the script defining the initial windows, was mapped to the URL portalLogin.servlet. One of the strengths of Ajax is the loose coupling between the client and the server. Our portal example uses Java as a back-end, but we don’t want to tie it to Java-specific features such as servlet filters and flexible URL rewriting. An alternative back-end architecture might use a request dispatch pattern, in which a single servlet, PHP page, or ASP.NET resource accepts all incoming requests and then reads a GET or POST parameter that specifies what type of action is being undertaken. For example, the URL for logging in to the portal might be portal?action=login&userid=user&password=password or, more likely, the equivalent using POST parameters. In Java, we might implement a request dispatcher approach by assigning a specific URL prefix, say .portal, to the dispatcher servlet, allowing us to write URLs such as login.portal. In our refactored component, we will generalize our assumptions about the back-end to allow either a request dispatcher architecture or the multiple address option that we used for our Java implementation. We don’t, however, need to introduce complete flexibility, so we’ll predefine a number of commands that the portal back-end will be expected to understand, covering login, showing the user’s portal windows, and adding and deleting windows from the portal. With these changes to the server in mind, let’s return our attention to the client-side implementation. Let’s begin our discussion of the portal refactoring by redefining the usage contract from the perspective of the page’s HTML; then we’ll delve into the implementation. Recall that the hook from our HTML page into the portal script was via the login, specifically through the login button: We’ll change the onclick handler to be a call to a function that will use our portal component. Let’s assume that the portal component will be instantiated via a script that executes once the page loads. A representative example of what this should look like is shown in listing 11.13. Listing 11.13 Portal creation and login function createPortal() { myPortal = new Portal( 'portalManager', b Base URL for portal Licensed to jonathan zheng Refactoring 455 { messageSpanId: 'spanProcessing', c Optional urlSuffix: '.portal' parameters } ); myPortal.loadPage(Portal.LOAD_SETTINGS_ACTION);