Completing the search	489

we were able to solve this problem with Opera and Safari, that is one less argument we have to face when determining whether it is a wise solution to use an XSLT transformation.

12.5.3Deciding to use XSLT

One of the discussions that we may have with our development team or boss is why we’re using XSLT in the first place. The argument starts out with “You have to generate the XML file dynamically on the server, so why don’t you just generate the results table instead?”

The major point that our fellow developers are trying to make is that we are using more processing in order to display the results to the user. That is true in the sense that the web page has to perform extra work when the browser renders the results table. Instead of loading one file, the Ajax code has to load two files, which then have to be combined.

We can dynamically build the table on the server with no major problems. The results table is displayed by using the responseText property of the XMLHttpRequest object and applying the returned value to our HTML element. There is nothing wrong with this method since it means one less step to deal with.

The one problem that we face when building the HTML table with the serverside code is the effort required to update the table if changes need to be made. As we discussed earlier in this chapter, we as developers may face many problems when building the table. We have to worry about quotes, tag syntax, attributes, event handlers, and so much more. If the users want us to change the order of the columns of the results table, we have to alter a bunch of code to perform this task.

By using XSLT, we are taking the building of the table away from our serverside code. The server can build a simplified version of the results table in XML format. XML format is very easy to look at and makes it easy to find mistakes. Also, the XSLT looks like an HTML page. We do not have to sit and count quotation marks or search through strings to see if a tag is there. With XSLT we can look directly at it and know that it is correct.

Another feature is that we can easily take a table layout that a web designer has designed and place it into an XSLT file. If we ever need to make a change such as swapping columns, it is as easy as cutting and pasting the data. No more scratching our heads wondering if the tags are still going to be right when we paste them. By using XSLT, we are removing the processing of the HTML from our dynamic code. This allows us to change the results table without any major problems.

And finally, using JavaScript lets us do some things very easily that we couldn’t do if we did the transformation on the server:

490CHAPTER 12

Live search using XSLT

■We can retrieve different XSL documents based on a theme, screen dimensions, language, and so on.

■We can retrieve an XML document and an XSL document without help from the server.

■We can examine an XML log file on our local machine without having control over the XML document structure.

When performing your daily tasks, you’ll find that Ajax gives you so many possibilities.

We still have one issue with the live search that we need to address: allowing the user to bookmark the results page.

12.5.4Overcoming the Ajax bookmark pitfall

There is one downside to using Ajax to perform searches: Bookmarking the page in the traditional manner is not an option. (This same problem occurs with frames and pop-up windows.) Bookmarks allow us to come back to the search results in the future without having to type in the request information, and they can be easily sent to friends and colleagues by email or messaging. Since an Ajax search does not require a postback to the server, we are not changing the URL of the page during the search, and therefore bookmarking the URL will simply mark the starting point for our application, not the results that we want to preserve.

An easy solution for this is to add a behavior that lets us remember the search. We can build a dynamic string that will be used to create a dynamic bookmark. This dynamic string will contain a direct link to the page it’s on and will include a querystring parameter with the search value. Therefore, when we write this string to the page to form the link, the user can either bookmark it (by rightclicking on the link) or copy the link, and her search will be automatically saved. We add this functionality of reading the querystring value when the page is loaded after we build the link.

The link can be built when our GrabNumber() function is executed. We add another span to our document so that we have a location to put this link on the page. In this case, the span has an ID of spanSave, as you can see in listing 12.11 by looking at the statement where getElementById is invoked. We can position the span wherever we want on the page so it is convenient for the user.

Listing 12.11 Altering the GrabNumber function to integrate a bookmarking link

function GrabNumber(){

var strLink = "<a href='" +