JavaScript Application Cookbook

Potential Extensions

The search engine is pretty useful the way it is. What’s even better is that you can make some significant improvements or changes. Here are some possibilities:

• Make it JavaScript 1.0 compatible

• Make it harder to break

• Display banner ads

• Add refined search capabilities

• Develop cluster sets

JavaScript 1.0 Compatibility

You know it, and I know it. Both of the major browsers are in the latter 4.x or early 5.x versions. Both are free. But there are still people out there clunking along with MSIE 3.02 or NN 2.x. I still get a surprising hit count of visitors with those credentials to HotSyte—The JavaScript Resource (http://www.serve.com/hotsyte/ ).

Since a search engine is pretty much a core feature of a web site, you might consider converting this app for JavaScript 1.0. Fortunately, all you have to do is go through the code listed earlier, line by line, figure out which features aren’t supported in JavaScript 1.0, and change all of them.

OK. I already did that, but admit it: I had you going. Actually, you’ll find the modified version in /ch01/js1.0/. Open index.html in your browser just like you did with the original. In this section, we’ll take a quick look at what will make the app work in JavaScript 1.0 browsers. There are three changes:

• No JavaScript source file (a browser issue really)

• No array sorting (with the sort() method)

• A workaround for the split() method

NN 2.x and MSIE 3.x do not support .js source files.^[2] The workaround for this is to embed the profiles array in nav.html. The second change eliminates the call to resultSet.sort() in line 90. That means your results will not be sorted in dictionary order, but by the way you have them chronologically listed in profiles. The last change is eliminating the split() method. JavaScript 1.0 does not support that either; the workaround takes care of that, but it degrades performance.

TANSTAAFL

That’s what my economics professor wrote on the chalkboard my freshman year at Florida State University. The translated acronym: Thar’ Ain’t No Such Thang As A Free Lunch. In other words, these changes give you older browser version compatibility, but cost you in functionality and code management.

Without support for .js files, you have to dump that profiles array into your nav.html. That will be quite unsightly and more unmanageable if you want to include those records in other searches.

The sort() method, while not critical to the operation, is a great feature. People might have to view all subsets of matched records because the records are in no particular order. Of course, you could place the results in the array alphabetically, but that’s no picnic either. Or you write your own sort method for JavaScript 1.0. The split() method is arguably the least of your troubles. The JavaScript 1.0 version of the app has a workaround, so it really isn’t an issue.

Make It Harder to Break

As it stands, you can pass the pipe character as part of the search query. Why not add the functionality to remove any characters from the query used as the string delimiters? That makes the app harder to break.

Display Banner Ads

If your site gets a lot of traffic, why not use it to make some extra money?

How? Try this. Suppose you want to randomly display five banner ads (no particular order in this case). If you have several ad image URLs in an array, you could pick one to load at random. Here’s the array.

var adImages = new Array("pcAd.gif", "modemAd.gif", "webDevAd.gif");

Then you might randomly display one on the results page like so:

document.writeln('<IMG SRC=' + ads[Math.floor(Math.random(ads.length))] +  '>');

Add Refined Search Capabilities

You can have some great programming fun with this concept. For example, suppose the user could select from array elements to search. Then the user could narrow seach results accordingly.

Consider displaying a set of checkboxes under the text field in nav.html.Maybe like this:

<INPUT TYPE=CHECKBOX NAME="group" VALUE="97">1997 Records<BR>
<INPUT TYPE=CHECKBOX NAME="group" VALUE="98">1998 Records<BR>
<INPUT TYPE=CHECKBOX NAME="group" VALUE="99">1999 Records<BR>

Use this checkbox group to determine which arrays to search, in this case profiles97, profiles98, or profiles99.

There are many things you can add to increase the user’s ability to refine searches. One easy one is to offer case-sensitive and case-insensitive queries. As it stands now, case does not matter, but you can change that by adding a checkbox allowing either style.

You could also expand search refinement by broadening Boolean searches from the current AND and OR searches to AND, OR, NOT, ONLY, even LIKE. Here is a breakdown of the general meanings:

AND

Record must contain both terms on the left and right of AND.

OR

Record can contain either of the terms on the left and right of OR.

NOT

Record must not contain the term(s) to the right of NOT.

ONLY

Record must contain this and only this record.

LIKE

Record can contain term(s) spelled like or sounding like.

This takes some work (especially LIKE ), but users would be quite amazed at your wizardry.

Cluster Sets

Another popular and useful technique is to establish cluster sets. Cluster sets are predefined word groups that automatically return predefined results. For example, if a user includes the term “mutual funds” anywhere in the query string, you could automatically generate results containing records featuring your company’s financial products. This technique takes a bit more planning, but it would be a great feature in a search application.

---

^[2] Actually that’s a stretch. Some versions of MSIE 3.02 do support JavaScript source files.