Ajax in Action phần 8 pdf

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.. We talked about the drawbacks of igating away from the

Implementing DHTML windows 447

With the portal windows open, we can test the functionalities built into the DHTML library without the Ajax functionality we are going to add next Here are some of the things we can do:

■ Maximize and minimize the windows by clicking on the button labeled

with an O.

■ Hide the window by clicking the button labeled with an X.

■ Open the DHTML window into its own pop-up window by clicking on the w.

■ Drag the window by holding down the left mouse button on the title bar and moving the mouse around Releasing the mouse button stops the drag operation

■ Resize the window by clicking on the green box on the lower-right corner and dragging it around the screen

You can see that the windows in figure 11.13 are in different positions than in ure 11.12

Now that we have the ability to position and resize the windows with the library,

we need to make our changes to the external js file The changes will allow us to call a function that utilizes Ajax to send the new property values to our database

Figure 11.13 Ajax portal showing windows with different positions

448 CHAPTER 11

The enhanced Ajax web portal

11.5 Adding Ajax autosave functionality

Using Ajax allows us to implement an autosave feature that can be fired by any event without the user knowing that it is happening Normally, the user would have to click a button to force a postback to the server In this case, we will be fir-ing the autosave with the onmouseup event, which ends the process of dragging and resizing events If we were to fire a normal form submission on the onmouseupevent, the user would lose all of the functionality of the page, disrupting her workflow With Ajax, the flow is seamless

11.5.1 Adapting the library

As we mentioned earlier, the code from JavaScript DHTML libraries is normally cross-browser compliant, which frees us from spending time getting cross-browser code to work correctly If you look at the code in the external JavaScript file, Ajax-Window.js, you’ll see a lot of functionality (which we will not discuss here because

of its length) There are functions that monitor the mouse movements, and one function that builds the windows There are functions that set the position of the windows, and another function that sets the size Out of all of these functions, we need to adapt only one to have our window save back to the database with Ajax

Adapting the DHTML library for Ajax

The DHTML library functions for dragging and resizing windows use many event handlers and DOM methods to overcome the inconsistencies between browsers The dragging and resizing of the windows is completed when the mouse button is released (“up”) Therefore, we should look for a function that is called with the onmouseup event handler in the AjaxWindow.js file It contains the following code, which is executed when the mouse button is released:

Adding Ajax autosave functionality 449

Although sometimes when we adapt libraries, it might take a lot of trial and error

to adapt them to our needs, in this case, the functionality is pretty ward Just add the following line, shown in bold, to your document’s onmouseupevent handler:

to the function SaveWindowProperties(), which initiates the request to the server

Obtaining the active element properties

After the user has moved or resized an element, we must update the server with the new parameters The DHTML window library uses CSS to position the ele-ments and to set their width and height This means that all we have to do is obtain the database ID, the coordinates, and the size of the window We can obtain the coordinates and size by looking at the CSS parameters assigned to the window that had focus We then can take these new parameters and send them to the server to be saved in the database with Ajax (listing 11.10)

d Grab window size

e Call Settings function

f Remove element reference

450 CHAPTER 11

The enhanced Ajax web portal

As you can see in listing 11.11, we obtain the ID of the window b by referencing the window object The ID that we obtained was assigned to the window when the library built it When it assigns an ID, it appends win in front of the number from the database id column; we can see that by looking at the JavaScript code that is building the windows

The x and y positions of the window are obtained c by referencing the leftand top properties in the stylesheet We also use the stylesheet properties to obtain the size d of the window by referencing its width and height properties After obtaining the information, we can call another function, Settings()e, which we will be creating shortly, to send our request to the server Once we call the function, we should remove the element object from our global variable elem-Winf To do this, we assign an empty string to the variable elemWin Now with the SaveWindowProperties() function complete, we can initiate our silent Ajax request to the server with the JavaScript function Settings()

11.5.2 Autosaving the information to the database

Ajax lets us send information to the server without the user even knowing it is happening We can see this in action with two projects in this book We can easily submit requests to the server as a result of both monitoring keystrokes, as we do in the type-ahead suggest (chapter 10), and monitoring mouse movements, as we

do in this chapter This invisible submission is great for developers since we can update the user’s settings without him having to lift a finger In most cases, reduc-ing steps increases the user’s satisfaction For this application, the action of the user releasing the mouse button is all we need to initiate the XMLHttpRequest object Now it’s time to initiate the process to send the request to the server

The client: sending the silent request

The XMLHttpRequest process in this case will not require anything sophisticated The user’s interaction with the form sends all of the form properties to our func-tion We first need to initialize the XMLHttpRequest object:

function Settings(xAction,xParams){

var url = xAction + ".servlet";

var strParams = xParams;

var loader1 = new net.ContentLoader(url,

Adding Ajax autosave functionality 451

For the function Settings(), we are passing the action string that contains all of our window’s properties We attach the parameters that we’re going to post back

to the server If we get a successful round-trip to the server, the loader will call the function BuildSettings() If we get an error during the round-trip, we will call the function ErrorBuildSettings():

The server: gathering information from the client

All we have left to do is to extract the values from our form submission The values were sent by our XMLHttpRequest object, which was triggered by the onmouseup event handlers We need to create our SQL query with this informa-tion and update the record in the database to save the new information We define an UpdateServlet for this purpose, which is shown in listing 11.11

public class UpdateServlet extends HttpServlet {

protected void doPost(

Listing 11.11 UpdateServlet.java (mapped to 'saveSettings.servlet')

b Get unique ID from request

c Get Window object from session

set-public static void savePortalWindow(PortalWindow window){

Listing 11.12 savePortalWindows() method

d Save changes Return simple text reply

Refactoring 453

To test the new functionality, log into the portal as our test user Drag the windows around the screen, and resize them so they are in different positions from their defaults Close the browser to force an end to the session When we reopen the browser and log back into the portal as that user, we see the windows

in the same position Move the windows to a new position and look at the base table We are automatically saving the user’s preferences without him even knowing it

We’ve now provided all the basic functionality for a working portal system, including a few things that a classic web application just couldn’t do There are several other requirements that we could classify as “nice to have,” such as being able to add, remove, and rename windows Because of limited space, we are not going to discuss them here The full code for the portal application is available to download and includes the ability to add, delete, rename, and adjust the win-dow’s properties without leaving the single portal page If you have any questions about the code in this section or need a more thorough understanding, you can always reach us on Manning.com’s Author Online at www.manning.com

Our code so far has been somewhat rough and ready so that we could strate how the individual pieces work Let’s hand it over to our refactoring team now, to see how to tighten things up and make the system easier to reuse

demon-11.6 Refactoring

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 sible 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, wewould provide further standalone servlets In a Java web application, the servlets

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 alter-native back-end architecture might use a request dispatch pattern, in which a sin-gle 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 por-tal?action=login&userid=user&password=password or, more likely, the equiva-lent 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:

<input type="button" name="btnSub" value="login"

onclick="LoginRequest('login')">

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

function createPortal() {

myPortal = new Portal(

'portalManager',

Listing 11.13 Portal creation and login

b Base URL for portal

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:

<input type="button" name="btnSub" value="login" onclick="login()">

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 ) {

d Call to load windows

456 CHAPTER 11

The enhanced Ajax web portal

earlier development of the script, recall that we had a servlet filter and two lets perform the back-end processing Throughout the rest of this example, we’ll assume a single servlet or resource, portalManager, which intercepts all requests

serv-to the portal back-end, as configured in listing 11.13 If we wanted serv-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(

11.6.2 Adapting the AjaxWindows.js library

Recall that the implementation of this portal used an external library called Windows.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 adapta-tion 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

Ajax-approach is evident We’ve branched a third-party library codebase, that is,

modi-fied 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 less as possible Let’s consider a less-radical approach of adaptation and see if we can rectify the situation Recall the last line of our constructor:

this.initDocumentMouseHandler();

Our initDocumentMouseHandler() method is an on-the-fly adaptation of the Windows.js library It just overrides the document.onmouseup as before, but within

Ajax-Refactoring 457

our own codebase instead Now our own method will perform the logic required

to perform the adaptation within the portal’s handleMouseUp() method This is shown in listing 11.14

initDocumentMouseHandler: function() {

var oThis = this;

document.onmouseup = function() { oThis.handleMouseUp(); };

initDocumentMouseHandler: function() {

this.ajaxWindowsMouseUpHandler =

ajaxWindowsMouseUpHandler;

var oThis = this;

document.onmouseup = function() { oThis.handleMouseUp(); };

},

Listing 11.14 Adaptation of the AjaxWindows.js mouse hander

b Store our own reference

this.ajaxWindowsMouseUpHandler = this.document.onmouseup;

This would achieve the same thing, but it’s a slightly more brittle proposition, since the contract in this situation is much looser This solution relies on the fact that we’ve included our script libraries in the appropriate order and that the AjaxWindows.js library has already executed the code that placed the mouseuphandler on the document It also assumes no other library has placed a different mouseup handler on the document or has performed some other wrapping tech-nique just as we’ve done

That’s probably about as much as we can hope to do with the library tion Let’s move on to the portal API The handleMouseUp() method reveals one of the three portal commands that the portal component has to accommodate When the mouse button is released, the saveWindowProperties() method is called

adapta-to save the size and position of the current window The following discussion will detail that along with the other portal command APIs

11.6.3 Specifying the portal commands

As already discussed, our portal component is primarily a sender of commands The commands that are sent are Ajax requests to a server-side portal manage-ment system We’ve already discussed the notion of commands and the formal Command pattern in Ajax, in chapters 3 and 5 Here is another opportunity to put that knowledge to use

The commands that we’ve supported up to this point in our portal are logging

in, loading settings, and saving settings We’re going to throw in the ability to add

c Call library function

d Add our functionality

Refactoring 459

and delete windows, which we alluded to although we didn’t show the full mentation We can think of each of these in terms of a method of our portal But before we start looking at code, let’s do a bit of prep work to help with the task of isolating change points What we’re referring to is the names of the commands themselves Let’s define symbols for each command name so that the rest of our components can use them Consider the following set of symbols:

Even though the language doesn’t really support constants, let’s assume that based

on the uppercase naming convention, these values are intended to be constant ues We could lazily sprinkle these string literals throughout our code, but that’s a fairly sloppy approach Using constants in this way keeps our “magic” strings in a single location If the server contract changes, we can adapt For example, imagine the ways in which the server contract could change, as shown in table 11.1

val-Now that we can reference commands by these symbols, let’s look at a generic mechanism for issuing the commands to the portal management server We need

a helper method that generically sends Ajax-based portal commands to the server Consider this usage contract:

Table 11.1 Public contract changes

A command is renamed (e.g., PageLoad gets

renamed to its verb-noun form LoadPage ).

Change the right side of the assignment of the

LOAD_SETTINGS_ACTION constant to the new value The rest of the code remains unaffected The server no longer supports a command Remove the constant, and do a global search for all

references Take appropriate action at each ence point.

refer-The server supports a new command Add a constant for the command, and use its name

within the code.

460 CHAPTER 11

The enhanced Ajax web portal

constants) and a variable number of arguments corresponding to the ters the command expects/requires The parameters are, quite intentionally, of the exact form as that required by the net.ContentLoader’s sendRequest()method The issuePortalCommand() method we’ve defined could be imple-mented as follows:

issuePortalCommand: function( commandName ) {

var actionParam = this.options['actionParam'];

var urlSuffix = this.options['urlSuffix'];

var ajaxHelper = new

net.ContentLoader( this, url, "POST", [] );

ajaxHelper.sendRequest

apply( ajaxHelper, callParms );

},

This method builds a URL based on the configuration options that we discussed

in section 11.6.1 If we have supplied a value for actionParam b, then it will be added to the parameters that are POSTed to the server d If not, we will append the command to the URL path e, adding the URL suffix if we have supplied one

in our options c The first function argument is the command name All ing arguments are treated as request parameters The URL that we have con-structed is then passed to the ContentLoader f, and the request is sent with the request parameters in tow g, as illustrated in the example usage shown previ-ously With this method in place, each of our portal command APIs will have a nicely minimal implementation Another “for free” feature of having a generic method like this is that we can support new commands that become available on the server without having to change any client code For now, let’s look at the commands we do know about

remain-b Get action parameter

c Get URL suffix

d Apply action parameter

e Apply URL suffix

f Create ContentLoader

g Send request

Refactoring 461

Login

Recall that our login button’s onclick handler initiates a call to the login()method of our page, which in turn calls this method The login command, at least from the perspective of the server, is a command that the server must handle

by checking the credentials and then (if they are valid) responding with the same response that our load-page command would perform With that in mind, let’s look at the implementation shown in listing 11.15

login: function(userName, password) {

in place does all the hard work

Load settings

Recall that the createPortal() function of our page calls this method to load the initial configuration of our portal windows The method to load the settings for the page is even simpler than the login method just discussed It’s just a thin wrapper around our issuePortalCommand() It passes the user as the lone param-eter that the server uses to load the relevant window settings, since the settings are on a per-user basis:

com-11.6.4 Performing the Ajax processing

As already noted, in this example we’re using an Ajax technique for handling responses in a script-centric way The technique relies on the fact that the

Refactoring 463

expected response is valid JavaScript code The thing that’s very desirable about this kind of approach is that the client doesn’t have to do any data-marshaling or

parsing to grok (geek-speak for understand) the response The response is simply

evaluated via the JavaScript eval() method, and the client is absolved from all further responsibility The negative side of this approach is that it puts the responsibility on the server to be able to understand the client-side object model and generate a syntactically correct language-specific (JavaScript) response The second downside of this approach is partially addressed by the popular vari-ety of this technique of using JSON to define our responses There are some server-side libraries that aid in the generation of JSON responses (see chapter 3), although these are moving more toward what we described in chapter 5 as a data-centric approach

For now, we’re going to stick to a script-centric system, so let’s look at our implementation and see what we can do to help it along Let’s start with our ajax-Update() function and its helper runScript():

prop-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.5 Refactoring 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.7 Summary

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 igating away from the page, but we were able to solve the problem by using Ajax

nav-to perform a request nav-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 intro-duces 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 refac-torings 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

Live search using XSLT

This chapter covers

■ Dynamic search techniques

■ Using XSLT to translate XML to HTML

■ Bookmarking dynamic information

■ Building a live search component

Understanding the search techniques 467

With Ajax, it’s easy to perform server-side actions while controlling what is pening on the client If a process takes an extended period of time, we can show animated GIFs that display messages that let the user know what’s happening The user can perform other actions while the server-side process is taking place and will be less likely to think that the browser has frozen

In this chapter, we use this Ajax technique to create a live search It utilizes Extensible Stylesheet Language Transformations (XSLT) to transform an XMLdocument into an HTML layout The XSLT translation is easier to maintain than the code to manually parse the XML and produce HTML using JavaScript state-ments It uses a tree-oriented transformation on a dynamically generated XMLdocument, which replaces the server-side code and the JavaScript on which the previous projects relied We are eliminating the hassles of manually making sure that all the HTML elements are formed properly

As with previous examples, we first develop the code in a straightforward way and then refactor it into a reusable component By the end of this chapter, you should understand the principles of using XSLT with Ajax and have a ready-rolled search component that you can drop into your own projects

12.1 Understanding the search techniques

When we perform searches, we are accustomed to seeing the page freeze while the search is conducted on the server (At least, this is the case on websites that do not have 1,200 clustered servers that perform a search over 8 billion pages in less than a second The budget constraints of your project may vary.) To eliminate the pause, some developers implement pop-up windows and frames The additional window is used to perform the processing so the user’s experience can be enhanced, but this also creates problems With Ajax, we can eliminate the com-mon delays of the classic form and frame submissions

12.1.1 Looking at the classic search

In a classic search process, when we include a search form on our website, one or more form elements are posted back to the server Google’s main search page is

an example Google’s search page (www.google.com) contains a single textbox and two search buttons Depending on what search action we select, the form either directs us to a list of records, which we can navigate, or takes us to a single result in that list This design is well suited for a page that doesn’t have any other functionality, but if it is part of a larger project, the design may cause problems, such as losing the state of the page, clearing form fields, and so on Figure 12.1 is

468 CHAPTER 12

Live search using XSLT

a diagram of the classic search model, where the entire page is posted back to the server for processing and a complete, new results page is returned

One source of delay is that database queries can take an extended period of time The browser is not accessible to the user until the results are displayed, causing the page to seem as if it has become frozen or inaccessible Developers attempt to alleviate this inaccessibility period by adding functionality to the page

to notify the user that the process is happening It’s important to note that this inaccessibility problem is not limited to search operations It can appear when updating or deleting records in a database, running a complicated server-side transaction, and so on

One way developers try to cope with this is to display an animated GIF, such as

a status bar, while the server is processing the submission A common question on forums such as JavaRanch (www.JavaRanch.com) is how this can be done The problem with an animated GIF is that it does not always run The GIF tends to remain on the first frame with Microsoft Internet Explorer and does not loop through the GIF animation cycle Developers have reported that some users think that their browser has frozen since they do not see the animation, and they click the refresh button or close their browser

The classic search form also suffers from the same problems as some of the previous examples in which the page has to be re-rendered The scroll position of the page may be lost because the new page is loaded at the top of the page instead of where the action took place The form fields may not stay filled in, which requires the user to enter the data again Developers attempt to solve these problems by using frames and pop-up windows, but they end up creating more problems Let’s take a look at the underlying reasons

Submit page

Render page Server

Display results

Browser

Process search and page generation

Figure 12.1 Classic search model showing the processing over a period of time

Understanding the search techniques 469

12.1.2 The flaws of the frame and pop-up methods

Developers have traditionally used frames, IFrames, and pop-up windows to avoid the problems with pages appearing to be frozen, losing scroll position, and

so on The frames and the pop-up window allow the processing to be continued

in another part of the web page, so the user can manipulate the part of the form where the action originated Not only can the user manipulate the form, but other JavaScript functions can be executed as well

The frame and pop-up windows have other added benefits The frame tion allows the returned record set to be scrolled while the search form elements remain in the view of the user The pop-up window permits the result to be dis-played in a separate window, taking the processing away from the main window With some parent/child window communication, we can pass data from the child window back to the parent window to return results The pop-up window is great for adding searches in large forms when the user needs specific information that can be hard to memorize The window can also be set to close after the processing

solu-is complete That solu-is useful when we want to perform updates without returning any data

Figure 12.2 shows how a search in a frame is implemented The bottom frame

is responsible for submitting the search request to the server, allowing the results

to be processed As a result of having the bottom frame initiate the search, the frame at the top of the window is still accessible to the user, unlike the classic search shown in figure 12.1

Although these solutions solve the problems that we talked about earlier, they also introduce new problems Frames have been (and still are) one of devel-opers’ worst nightmares The main problem is navigation, since we do not know how the frame will react with the browser We wonder how the back button will affect the frame Will the frame take us to the right page, will it destroy our

Submit frame

Render frame Server

Display results

Browser

Process search and frame generation

Figure 12.2 Process flow of a search executed in the frame model

470 CHAPTER 12

Live search using XSLT

frameset, or will it just not seem to work? These are the questions that are cally in our minds when testing And what if the pages are opened in a browser that does not support framesets? To avoid this latter problem, we would have to include frame-detection scripts on the page, adding more weight to our applica-tion and introducing more code to manage, and thus increasing the complexity

typi-of our codebase

Pop-up windows, on the other hand, are subject to pop-up blockers as users increasingly turn them on Pop-up windows should have no problem if they are explicitly initiated by the user’s button click, but pop-up windows can be spawned

by the browser automatically, such as an onload or onunload pop-up These onload pop-up windows are often prevented from opening since they tend to be abused as advertisements Some users block all pop-up windows—which means users will never get their results since no window will open

Other problems can occur with pop-up windows, such as when the child dow appears underneath its parent; the pop-up window cannot be seen since it is

win-covered by the parent window This is known as a pop-under Another problem can

happen when an action takes place in the parent window If the user clicks a link

or refreshes the page, the action can sever the child-parent relationship, resulting

in loss of communication between the windows When the page refreshes, the pop-up window object is destroyed; there is no way to carry the object from page

to page in a reasonable manner

As you can see, although the frame and pop-up methods solve the problems inherent in traditional form submission, their solutions may lead to bigger prob-lems One way to fix these problems is to use Ajax Ajax handles server commu-nication independently of the browser page, which allows our animations to play and maintains the page state; we do not have to worry about outside factors such

as pop-up blockers and users closing the window because they think it is frozen

12.1.3 Examining a live search with Ajax and XSLT

We can improve the functionality of certain search features on a website by

turn-ing the search into a live search, which is how some developers are namturn-ing the

functionality of Ajax searches This search is performed without posting the entire page to the server (as in the traditional search), which means that the cur-rent state of the page can be maintained In addition, we can run JavaScript and GIF animations without any major problems, since the results are displayed within the browser with innerHTML or other DOM methods

Let’s say we have a search that triggers a long database transaction that appears to lock the page With Ajax, the animation can start when the database

Understanding the search techniques 471

transaction starts When we begin to output the results, we can simply set the CSSdisplay property of the animated image to none, which will make the animation disappear A variation on this is to place the animation image in the output loca-tion where the results are to be displayed When the transaction is complete, we replace the GIF with the results, so the wait image is removed Either way, the user can still use the form while the XMLHttpRequest object is processing the data of the server

Let’s look at a popular example of allowing the user to work with an tion while processing is being done on the server: Google Maps We send out a request to the server for, say, restaurants on Main Street, and we are still able to manipulate the map while the server processes our request We do not have to wait as we would with a normal form submission The server-side process then returns the results to the page, where they are displayed to the user In the same way, our live search allows the user to interact with the page while the server is processing the data Figure 12.3 shows Ajax’s process flow

The Ajax approach to handling searches and long transitions allows us to eliminate the problems that we have faced with the other options used in the past This live search feature is not only useful when used with a search engine like Google or Yahoo, but it can also be helpful for smaller lookups For instance, we can use a live search to perform a lookup to a database table to retrieve informa-tion for some of the form fields, such as an address, based on what the user has entered so far—all while the user is filling in other fields Any long transaction with the server can be turned into a live process, with the server providing incre-mental updates to the client, which are displayed in an unobtrusive way (see chapter 6) With Ajax, we can improve data transfer and get the results to the cli-ent in a richer environment

Figure 12.3 Process flow of the Ajax model The server-side process generates data, which the client-side code inserts into the page directly Less bandwidth is used, and the user interface is smoother.

472 CHAPTER 12

Live search using XSLT

12.1.4 Sending the results back to the client

When the server returns the result of a live search, we can send the information back to the client in one of several ways We can format the results as XML, plain text, or HTML tags In previous examples, we created an XML document

on the server The JavaScript code on the client side then called XML DOMmethods to build the results table on the client side by looping through the XML nodes This process used two loops The first loop was on the server when

we built the XML document, and the second was the loop to build the HTMLtable on the client

We can avoid the client-side XMLDOM loop by building the HTML table on the server before we send it back, rather than building the XML file With this technique, we concatenate HTML tags into a large string, similar to what we did to create the XML document However, instead of building it with XML tags, we use table elements The HTML string is returned to the client, and we can apply it directly to an element’s innerHTML property In this case, we would use the XMLHttpRequest object’s responseText property since we would have no need to navigate through the nodes

The problem with these techniques is that—whether it happens on the server

or the client—there is a requirement to loop through the data and build the table dynamically If we need to make changes to the table format in the future, it may

be a tedious task, depending on the complexity of the table Adding or ing a column may cause a problem, since we must alter the code inside the loop

subtract-We also need to take into account the extra quotes that are contained inside our string; we must make sure that we are escaping the quotes when building the string Also, if we embed JavaScript into this HTML tag, it adds even more quotes and apostrophes to worry about—we have to verify that all of the tags are closed and that they are properly formatted The only way we can do that effectively is by examining the text after we build the string

One option that lets us avoid these problems is to use XSLT With Ajax, it is possible to combine an XSLT file with an XML document and display the results, thus avoiding DOM methods If a developer knows XSLT and is not great at cod-ing JavaScript, this may be an excellent solution

One thing to note about an Ajax search is that it does not require a postback to the server, and consequently the URL of the page does not change to match the search results Therefore bookmarking the URL will not give us the results we want In a classic search, such as Google, we can easily copy a URL from a page found by the search and paste it into an e-mail; when the recipient clicks the link,

The client-side code 473

they see the results However, with an Ajax search, we need to add a little extra code to make this happen We will look at this solution in section 12.5.4

12.2 The client-side code

Formatting XML data using XSLT is a popular technique since XML has a tured layout that can be easily manipulated In previous projects such as the type-ahead suggest in chapter 10, we used JavaScript, XML, and DOM manipulation to create the HTML that we were to display In this example, we use XSLT to produce the same effect

struc-XSLT enables us to format our data by building the HTML layout in another file and combining it with the XML document The XSLT file takes all of the guesswork out of navigating through the XML nodes and building our tables, menus, and HTML layouts With Ajax, we can retrieve a static or dynamic XMLfile and a static or dynamic XLST file from the server, and combine them on the client to build our HTML document XSLT could also be undertaken on the server side, but we’ll look at client-side transformations here

12.2.1 Setting up the client

For this project, we perform a phonebook search on a user’s name We use one textbox and one submit button to do this Our simple search form is shown in list-ing 12.1

<form name="Form1" ID="Form1"

onsubmit="GrabNumber();return false;">

Name: <input name="user" type="text"/>

<input type="submit" name="btnSearch"

Listing 12.1 Client-side form

b Add onsubmit handler

c Insert textbox

d Add submit button

e Add div for results

474 CHAPTER 12

Live search using XSLT

disabled In that case, the form would have to be submitted back to the server, and we could use a classic search form to support that user However, we are not adding that functionality to this project.)

The form that we have created is basic, containing only one event handler to initialize the XMLHttpRequest The textbox c and the submit button d are added to the form to collect the user’s search criteria If we wanted to get fancy, we could also add an onblur handler to the textbox that calls the function Grab-Number(), and when the user removes focus from the textbox, it would perform the search In this example, we stick with the onsubmit handler to perform the search

We next add our div element e to the document as the output location for the search results We can position the div wherever we want the results to appear on the page The ID is added to the div so that we can reference it to add the results and an animated GIF We are not required to use a div element to out-put the results We could easily output the results into a cell in a table or even a span; in fact, we can use any HTML element whose innerHTML property can be manipulated We are using a div because it is a block element, which contains a line break before and after the element The div also takes up 100 percent of the available width of the browser, making it easier for larger results tables to be dis-played to the user

It is important to note that the onsubmit handler must return false when the event handler is executing This informs the browser that the form should not be submitted back to the server, which would trigger a full-page refresh and inter-rupt our JavaScript programming of the form We’ll see the return value in listing 12.2 in the next section

12.2.2 Initiating the process

In this example, we use two files on the server: an XML document and an XSLdocument The XML document is created dynamically by PHP when the client requests it The PHP code takes the user input posted from the page, runs a query against the database, and then formats the results into an XML document The static XSL document transforms our dynamic XML file into an HTML document Because it is static, it does not have to be created by the server at the time of the client request, but can be set up ahead of time

Just as with the other projects in this book, we are using a function to initialize our XMLHttpRequest object We gather this information and call the function in listing 12.2

The client-side code 475

This function assembles the information needed for the call to the server, sets the

“in progress” image, and calls the server, which will dynamically build the response data based on the querystring value we send The first parameter of the LoadXMLXSLTDoc() function is the URL of the PHP page that generates the XMLdocument, combined with the querystring, which is built by referencing the value

of HTML form field b The second parameter is the name of the XSLT file c

that is used in the transformation of the XML data The third parameter that we need for the function LoadXMLXSLTDoc() is the ID of the div where the search results are to appear The ID is just the string name of the output element and is not the object’s reference; in this case, the string is “results”

The next step is to add the loading image to the web page, using DOM ods The image element d is created and the source attribute e of the image is set We append the newly created element f to the results div This places the image file on the page when our function is called from the onsubmit handler of the form It is important to show the user visual feedback, such as a message or an image, to indicate that the request processing is happening This eliminates the chance of the user repeatedly clicking the submit button, thinking that nothing has happened, since Ajax is a “silent” process

The last step is to call the function LoadXMLXSLTDoc() g, which initiates the process of sending the information to the server The LoadXMLXSLTDoc() function that we will build in section 12.4 will handle calling our ContentLoader(), which requests the documents from the server By specifying the output location as a

Listing 12.2 Initiation function

Create the function

b Build XML URL

c Build XSL URL

d Create image element

e Set the source

f Append image to page

g Start loading

476 CHAPTER 12

Live search using XSLT

parameter instead of hard-coding the value into our LoadXMLXSLTDoc() function,

we can reuse this function multiple times on the same page without having to add multiple functions or if statements to separate the functionality Therefore, we redirect the output of different searches to different parts of the page But before

we do this, let’s look at how we build the XML and XSLT documents on the server

12.3 The server-side code: PHP

In this section, we create the dynamic XML document for this project using the popular open source scripting language PHP (remember, Ajax is able to work with any server-side language or platform) The XML document is dynamically gener-ated from the result set of a database query at the time of the client’s request We also show how to create the static XSLT document, which resides on the server and is retrieved each time the dynamic file is requested Both of these documents are sent back to the client separately when the ContentLoader requests each of them in two separate requests, as shown in listing 12.7 The XSLT transforms our dynamic XML document on the client and creates an HTML table that is dis-played to the user

12.3.1 Building the XML document

Since we are using XSLT, we need a structured XML document that is just a simple listing of information, so the XSLT file can perform a basic transformation For this project, we develop a dynamic XML file when the PHP file is requested from the client

Designing the XML structure

Before we can start to build the XML file, we need to create a template for that file The template should reflect the structure of the data returned by the search For our address book example, we’ll return the company name, the name of a contact person, the country, and a phone number Listing 12.3 shows our basic XML template containing the four fields

The server-side code: PHP 477

</entry>

</phonebook>

The first element is phonebook The next one is the entry element, which contains the subelements that hold all the details that relate to each contact found in the query If we have five results, there will be five entry elements in our XML docu-ment The company name is displayed in the company element We are also add-ing the contact name, the country name, and the phone number We are not limited to just these fields; we can add and subtract fields depending on the infor-mation we want to display

Instead of displaying an alert message to the user if results are not found, we can create an entry displaying that information to the user This makes it easy for

us to return the result to the user without having to add any extra client-side code The code in listing 12.4 is almost the same as that in listing 12.3, but this time we are inserting text into the XML elements that we want to display to the user to show that no results were returned

infor-no information If we do infor-not want to display “N/A”, we can add a nonbreaking space, &nbsp;, instead, which allows the table cells to show up If we were to not add any information, the cells would not appear in the table

As you can see, the XML format has a very simple structure If this XML file were static, it would be rather easy for any user to add a new customer to the file Because we are creating it dynamically, we will have to create a loop, which builds our XML document from our result set

Listing 12.4 XML file with no results

b Display “No Results”

for company name

c Display “N/A”

for remaining fields

478 CHAPTER 12

Live search using XSLT

Building the dynamic XML document

As always, we build our XML document on the server Following our policy of using different server languages for our illustrations, we’ve implemented the server code for this chapter in PHP Ajax can work with any server-side language, and the fine details of the server code aren’t important to our story here Listing 12.5 shows the server-side code The code obtains the querystring parameter and generates a result set of a database query We then loop through the result set and create an entry in the XML file for each phone entry returned from the query, fol-lowing our basic template (listing 12.4)

Listing 12.5 phoneXML.php: Server-side XML generation

b Declare mime type

c Connect to database

d Populate query

e Test results

f Iterate through results

g Show empty dataset

The server-side code: PHP 479

In order for this dynamic XML document generation to work, we must set the document’s type to text/xmlb; if we skip this step, the XSLT transformation may not take place, especially with Mozilla and Firefox

The data that we are searching for is stored in a database table We need to select the relevant entries In this case, we are using PHP’s built-in MySQL func-tions to talk to the database directly, in order to keep things as simple as possible

We connect to the database ajax running on the local database server as the user

ajax with password action c We then construct our SQL query string using the request parameter passed in from the client code to populate the WHERE clause d For a more robust server-side implementation, we recommend an Object-Relational Mapping system such as Pear DB_DataObject (see chapter 3) rather than talking directly to the database as we have done here However, the current implementation is simple and can be easily configured by readers wanting to test the example for themselves Having returned the result set, we check whether it is empty e, and then either iterate over it f to create the phone entries, or print out the “No Results” message g

12.3.2 Building the XSLT document

We can use XSLT to transform our XML file into a nice HTML table with only a few lines of code The XSLT document allows for pattern matching if necessary

to display the data in any format we want The pattern matching uses a template

to display the data We loop through the source tree nodes with the XSLT to play the data The XSLT takes the structured XML file and converts it into a view-able format that is easy to update and change Our XSLT document will be defined statically

dis-Explaining the XSLT structure

An XSLT transformation contains the rules for transforming a source tree into

a result tree The whole XSLT process consists of pattern matching When a pattern is matched against the source tree elements, the template then creates our result tree

The result tree structure does not have to be related to the source tree ture Since they can be different, we can take our XML file and convert it into any format we want We are not required to stick with a tabular dataset

This XSLT transformation is called a stylesheet since it styles the result tree The stylesheet contains template rules, which have two parts The first part is the pattern, which is matched against the nodes of the source tree When a match is

480 CHAPTER 12

Live search using XSLT

found, the XSLT processor uses the second part, the template, which contains the tags to build the source tree

Building the XSLT document

Building the XSLT transformation for this project is rather simple Since we are developing a table, we won’t need any special pattern matching; instead, we will loop through the source tree element nodes The template that we’ll develop outputs an HTML table with four columns Listing 12.6 shows the XSLT file for this project

encod-Listing 12.6 XSLT file

b Set XML version and encoding

c Specify XSLT namespace

d Set template rule

e Add table element

f Create heading row

g Loop through phonebook entries

h Output the entry data