Chapter 7. Performing Searches

only for RuBoard - do not distribute or recompile

Chapter 7. Performing Searches

The web provides a limited number of ways that enable users to select what they re interested in seeing. A lot of Web sites start out as a collection of pages containing static information with embedded hyperlinks that guide visitors to various places within the site. This is standard hypertext navigation and it probably accounts for the majority of user activity on the Web. It s a useful way to direct people, but it only goes so far. As you add more content to your site, sooner or later you ll need to provide some other way for visitors to find what they want. Links have a limited usefulness in this respect, because although they are very easy to provide (just put a bunch of <a href> tags into your pages), they are also more limiting to the user. They express the choices you want to provide or that you can anticipate in advance, and these are not necessarily what the visitor wants.

As an alternative, search forms can be used to give your visitors capabilities that are difficult to provide using hyperlinks. You can allow users to specify directly what they want by filling in the form to indicate what kind of information is of interest and submitting it (sending it back to the Web server) to have the request acted on. This means more work for you as a Web developer because you have to set up or write some kind of program to process the form. But it enables users to say explicitly what they want, and helps you to take them directly to the information in which they re interested.

Search applications are a natural context in which to use your database on the Web, because searching is one of the things databases are designed to do well. Coupling a Web-based front end with a database back end is an extremely popular way to make all kinds of information available to visitors without trying to figure out in advance what data they might want to look for. By keeping your information in the database and generating results on-the-fly, your Web pages are always up-to-date something not true for sites that consist of static pages.

This chapter shows you how to build search applications for which you provide a search form and tie it to your database to give your visitors the ability to get at the information in which they re interested. In so doing, you move from deciding for site visitors what their options are to allowing them a measure of control over what content they see. There s an important concept here; namely, that you can use your database to let users help themselves.

Search applications of this type vary widely in scope and capability, ranging from simple things such as finding a word in an online dictionary to more complex searches based on multiple parameters for example, all used minivans more than three years old with less than 100,000 miles, with a V-6 engine, cruise control, air conditioning, and a luggage rack. Regardless of the complexity of the search, however, most such applications have several things in common. Obviously, you always must run some kind of query on behalf of the user, but implementing user-directed search applications actually involves quite a bit more than that. You re responsible for each of the following things:

• Designing a form that enables users to specify what they are interested in. This is the primary interface to your search engine, so the form must include fields for every aspect of the search over which you want the user to have control. (For example, cars may come in different colors but unless you provide an appropriate element in the search form, users can t ask for cars in a particular color.)

• Identifying the search parameters when the form is submitted and constructing an appropriate SELECT query from them. The main issue here is constructing the proper WHERE clause the part that indicates which records to retrieve. The clause may be simple or complex, depending on the number of parameters the user can specify. There may be other issues as well. If you let the user choose the sort order, the search parameters affect how you construct the ORDERBY clause. If you allow the user to select from among alternative display formats, the choice may affect the amount or type of information that you retrieve. (One common example: Allowing the user to specify how many hits to display per page affects how many records you retrieve at a time.)

• Issuing the query and presenting the results. In this phase of the application, you deal with issues such as how many records are returned by the query (which may affect whether you display a single page or multiple pages), the complexity of individual records, and the destination to which you send the information.

  (It s most common to display results in a browser window, but you might provide the information in other formats, such as a downloadable tab-delimited file, or a reduced-content display for handheld devices.)

These phases sometimes interact, which makes it more difficult to design your application (or more interesting, depending on how you look at it). If you present search results in a standard sort order, you can build the order into your script and apply it uniformly regardless of the search parameters entered by the user. On the other hand, if you give the user some control over how to sort search results, that affects the design of the search form because you must provide a field for selecting the order. It also affects query construction because the ORDERBY clause must be built on-the-fly based on user input.

In the next section, we ll begin by writing a search application that is moderately complex, but still simple enough to understand easily. The particular scenario is that of an application designed for use by realtors and their customers: It presents a form enabling people to search through a database of listings for residential properties. The form provides fields for a number of different parameters such as location, architectural style, and price. (I list location first based on the realtor s axiom, location, location, location. ) This scenario is specific for concreteness, but the techniques we ll cover are more general and can be used in many types of search applications. As you read, think about how you d apply the material here to the tables in your own database.

After building the initial version of this application, we ll create a revised version that adds other features such as the capability to deal with a large number of hits by presenting multiple-page results that include next page and previous page links. The revised version also will show pictures with the results, enable the user to search additional fields, send listings to other people by email, and more.

Finally, we ll switch gears a bit and consider when it s reasonable to present information via the search by clicking links paradigm that is, when it can be useful to present a set of pages by using indexes that consist of link lists. Despite my earlier disparagement of link-based navigation as a means of allowing users to search for information, in some situations this is a helpful way to provide access to data. A typical kind of scenario to which this technique applies is when you have some type of organization, such as a business with many staff members. To help visitors find people by name, it s easy to provide an index consisting of letters of the alphabet that are links to different sections of the directory that list people whose names begin with the corresponding letter. Naturally, we ll generate the links dynamically using information in the database so that they remain current without a lot of manual editing. Sometimes people implement directories using static pages, but it s really a headache to maintain this kind of list if the information changes very often. A database-backed solution makes it much easier to keep the information up-to-date; changes to the database translate immediately into updated content if you generate the indexes by querying the database.

only for RuBoard - do not distribute or recompile