The project is fairly simple. Develop an on-line addressbook and use it to store names, addresses, phone numbers, and anything else that may be related to an addressbook. The code to search the addressbook and display results will be available to all, but the code to add/edit/delete entries should be somehow protected. Otherwise, you may have every Internet jerk-off adding Bart Simpson type entries (Semour Butts, Ivanna Tinkle, etc.) and deleting entries you may want to keep.

Here are the questions we should be asking ourselves before we develop the database schema:

1. Can a person have more than one address or phone number?
2. Can more than one person have the same phone number or address?
3. Do we want to be able to search on a person's first and/or last names separately?
4. Do we want to be able to search for phone numbers by area code or prefix?
5. Do we want to be able to search for records in a particular city or state?

Let's answer each of these questions. Obviously, one person can have more than one phone number. Hell, I have friends that have so many numbers there isn't enough spaces to write them all in a conventional addressbook! As for more than one address - well, suppose you want to store someone's work address as well as their home address, or maybe a person has a summer home up north and a winter home in Florida. It would be nice to be able to store all of them.

What about two (or more) people with the same address or phone number? Obviously married couples, roommates, or those that live together would make this true.

What about searching? With a conventional addressbook, there is usually a thumb index with each letter of the alphabet on it. With just a few dozen phone numbers, this type of search system is adequate. But what if you have hundreds or even thousands of numbers to store? Scrolling through a couple of hundred C's may be tedious. So we'll create a search utility that can search by last and first names, as well as by area code and prefix. Also, we'll include a way to specify the city and state in the search criteria.

Applications

So how many applications will we need to develop? We'll need one app to do each of the following:

Classes

By now, you may have already figured out that we're going to be developing Perl handlers and utilities instead of one giant cgi to do the work. I'll refer to each handler and utility as a class (you could also call them packages). Why do it this way? I like to think of programming as a 'divide and conquer' procedure. If everything is crammed into one script, then editing, debugging, and making changes can be a nightmare. However, if everything is separated, it makes it easier (for me, at least) to find the bug or implement a new feature. Also, this will help us adhere to our rule from the Introduction about the code fitting on one page. It will also help with another rule, making the code easy for someone else to edit.

So, we'll need develop handler classes to do each of the following:

Additionally, we'll develop utility classes to:

Putting any methods for working with records into a class will guarantee we never have to rewrite the same code twice. Why should we use a separate class to hold all the SQL? It will ease future conversion (if necessary) to another database.

You may be asking yourself what the difference is between a Perl handler and a regular utility class. A handler contains methods that 'handle' particular tasks. A utility class provides methods to the handler that are used to work with the data. If the difference is still not clear, don't worry. As we develop this project, the distinction will become more evident.

Coming Next: Step 2 - Developing the database schema