AJAX In Action [238]
Supporting Opera and Safari
If you recall, we have a problem with Opera and Safari not supporting either the transformNode() method or the XSLTProcessor object. We have two options for supporting Opera and Safari. The first one is to use Ajax to send the files to a server-side page for processing. The server-side code can combine the XML and Licensed to jonathan zheng 488 CHAPTER 12 Live search using XSLT XSLT documents. We would then fetch the result of the transformation using a single ContentLoader object, rather than fetching the XML data and the XSLT stylesheet independently. This is not the best solution since we have to use two round-trips to perform the transformation. Our second option is to submit the entire page back to the server without the use of Ajax. The server in this case would handle the submission and combine the XML and XSLT documents on the server as we would do traditionally. This approach is better because it lets all users use the search. If a person is using an early version of a browser that does not support the XMLHttpRequest object, then that user can use the form. If we used the Ajax-only technique, the people without the ability to use Ajax would not be able to retrieve the two files for processing. Our second approach gives them the ability to use the form since Ajax is not required. In order to add this functionality, we need to make two changes to the LoadXMLXSLTDoc() function, as shown in listing 12.10. We must alter the first if statement to include a check for the XSLT processor. Then we must add an else statement to force the submit back to the server. Listing 12.10 Altering LoadXMLXSLTDoc to support Opera and Safari function LoadXMLXSLTDoc(urlXML,urlXSL,elementID){ var reqXML; var reqXSL; if (window.XMLHttpRequest && window.XSLTProcessor){ //...do Mozilla client XSLT }else if (window.ActiveXObject){ //...do Internet Explorer client XSLT }else{ document.Form1.onsubmit = function(){return true;} document.Form1.submit(); } } In listing 12.10, we remove the onsubmit event handler inside the else branch of the conditional check so that we submit the form to the server. Without removing the onsubmit handler, the form would not submit back to the server. The server-side page then has to do all of the processing and put the element on the form. In return, we get a fast response for those users who can combine XSLT with JavaScript, and we do not alienate the users who do not support Ajax or the XSLTProcessor. Remember that Ajax is giving us the benefit of not having to re-render the entire page, which can lose the current state of the page. We do not have to worry about the scroll position, form values, and so on. Since Licensed to jonathan zheng 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.3 Deciding 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