|• Efficient Client-Side Searching||• Using Delimited Strings to Store Multiple Records|
|• Multiple Search Algorithms||• Nested for Loops|
|• Sorted and Portioned Search Results||• Wise Use of document.write( )|
|• Scalable to Thousands of Records||• Using the Ternary Operator for Iteration|
This approach has some significant benefits, chiefly reducing the server’s workload and improving response time. As good as that sounds, keep in mind that this application is restricted by the limitations of the user’s resources, especially processor speed and available memory. Nonetheless, it can be a great utility for your web site. You can find the code for this application in the ch01 folder of the zip file. Figure 1.1 shows the opening interface.
This application comes equipped with two Boolean search methods: AND and OR. You can search by document title and description, or by document URL. User functionality is pretty straightforward. It’s as easy as entering the terms you want to match, then pressing Enter. Here’s the search option breakdown:
Entering terms separated by spaces returns all records containing any of the terms you included (Boolean OR).
url: before a full or partial URL
returns those records that match any of the terms in the URL you
Don’t forget your zip file! As noted in the preface, all the code used in this book is available in a zip file on the O’Reilly site. To grab the zip, go to http://www.oreilly.com/catalog/jscook/index.html.
It’s also nice to be able to search by URL. Figure 1.3 shows a site search using the url: prefix to instruct the engine to search URLs only. In this case the string html is passed, so the engine returns all documents with html in the URL. The document description is still displayed, but the URL comes first. The URL search method is restricted to single-match qualification, just like the default method. That shouldn’t be a problem, though. Not many people will be eager to perform complex search algorithms on your URLs.
This application can limit the number of results displayed per page and create buttons to view successive or previous pages so that users aren’t buried with mile-long displays of record matches. The number displayed per page is completely up to you, though the default is 10.
All client-side applications depend on the resources of the client machine, a fact that’s especially true here. It’s a safe bet the client will have the resources to run the code, but if you pass the client a huge database (more than about 6,000 or 7,000 records), your performance will begin to degrade, and you’ll eventually choke the machine.