Tải bản đầy đủ - 0 (trang)
Chapter 1. The Client-Side Search Engine

Chapter 1. The Client-Side Search Engine

Tải bản đầy đủ - 0trang

within the requested web pages. This makeshift database is simply a JavaScript array. Each record is

kept in one element of the array.

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.

Figure 1.1. 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).

Placing a plus sign (+) before your string of query term(s) matches only those records

containing all of the terms you enter (Boolean AND).

Entering url: before a full or partial URL returns those records that match any of the terms

in the URL you enter.

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.



Figure 1.2 shows the results page of a simple search. Notice this particular query uses the default (no

prefixes) search method and javascript as the search term. Each search generates on the fly a results

page that displays the fruits of the most recent search, followed by a link back to the help page for

quick reference.

Figure 1.2. A typical search results page



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.

Figure 1.3. Results page based on searching record 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.



1.1 Execution Requirements

The version of the application discussed here requires a browser that supports JavaScript 1.1. That's

good news for people using Netscape Navigator 3 and 4 and Microsoft Internet Explorer 4 and 5, and

bad news for IE 3 users. If you're intent on backwards compatibility, don't fret. I'll show you how you

can accommodate IE 3 users (at the price of functionality) later in this chapter in Section 1.5.

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.

I had no problem using a database of slightly fewer than 10,000 records in MSIE 4 and Navigator 4.

Incidentally, the JavaScript source file holding the records was larger than 1 MB. I had anywhere

between 24 and 128 MB of RAM on the machine. I tried the same setup with NN 3.0 Gold and got a

stack overflow error—just too many records in the array.

On the low end, the JavaScript 1.0 version viewed with MSIE 3.02 on an IBM ThinkPad didn't allow

more than 215 records. Don't let that low number scare you. The laptop was so outdated you could

hear the rat on the exercise wheel powering the CPU. Most users will likely have a better capacity.



1.2 The Syntax Breakdown

This application consists of three HTML files (index.html, nav.html, and main.html ) and a JavaScript

source file (records.js). The three HTML files include a tiny frameset, a header page where you enter

the search terms, and a default page in the display frame with the "how-to" instructions.



1.3 nav.html

The brains of the application lie in the header file named nav.html. In fact, the only other place you'll

see JavaScript is in the results pages manufactured on the fly. Let's have a glimpse at the code.

Example 1.1 leads the way.

Example 1.1. Source Code for nav.html



1





2

3 Search Nav Page

4

5

6

174

175

176

177

178



182

183



190

191



195

196




179



180

Client-Side Search Engine

181



184


185

onsubmit="validate(document.forms[0].query.value);

return false;">

186



187



188



189



192



193

Help

194



197

198

That's a lot of code. The easiest way to understand what's going on here is simply to start at the top,

and work down. Fortunately, the code was written to proceed from function to function in more or less

the same order.

We'll examine this in the following order:











The records.jssource file

The global variables

The functions

The HTML



1.3.1 records.js

The first item worth examining is the JavaScript source file records.js. You'll find it in the