In general, the Web would be a pretty useless place if it weren’t for HTML forms. Forms provide an interface for the client to submit information to the web server. The most common form interfaces include search engine interfaces, e-commerce interfaces, and data administration interfaces.
This chapter and the next focus primarily on data administration interface forms. Data administration interfaces are common in many data-driven web sites. For example, if you ran a web site that sold widgets, you’d have a pretty extensive database structure, comprised of many tables containing an assortment of relevant information. This site would also likely contain an extensive set of administration pages, where each administration page permitted administrators to update, insert, and delete records into the various database tables.
This chapter does not focus on creating HTML forms, or reading form variables through an ASP page—it’s assumed you are familiar with those topics. (If you are a little rusty, don’t worry; there’s a brief discussion on each of these topics early in the chapter.) What we will be focusing on heavily throughout this chapter and the next is the art of form reuse.
Code reuse has many advantages, the paramount one being that developers who practice code reuse become more efficient developers, writing less buggy code. Code reuse obviously saves time in the long run, since you don’t have to continuously reinvent the wheel. Code reuse also produces less buggy code. There’s a positive correlation between the number of lines of code one writes and the number of bugs present. Ergo, writing fewer lines of code (through reuse) leads to fewer bugs. Furthermore, the more often a particular piece of code is reused, the more certain you can be that the reused code is bug-free. This benefits developers in the debugging phase; if there is a bug in the system, there’s a much greater probability it came from a new piece of code than from a code module that has been used in several previous projects without fail.
Code reuse also benefits the end user. For example, all the Microsoft Office applications share the same code for a number of tasks, such as the toolbar functionality and the menu system. Such code reuse provides the end user with a consistent look and feel, flattening the learning curve associated with the various Office applications.
ASP provides extensive opportunities for code use. Server-side includes and the Server.Execute method, which we discussed in Chapter 1, allow developers to modularize their code; COM components, which we’ll discuss in Chapter 7, aid in business logic; as we discussed in Chapter 4, VBScript provides classes that enable the encapsulation of complexity and the ability to hide implementation details. Despite these features, many ASP developers fail to make a serious effort at code reuse.
I think part of the problem is that ASP pages are created using scripting languages. Generic scripts, by their nature, are often small and simple, performing a discrete task. Furthermore, scripts often each have a unique task to complete. For this reason, rarely do ideas of code reuse or modularization come into mind when developing a script.
ASP projects would benefit enormously if ASP developers paid greater attention to issues of code reuse. More often than not, a vast number of ASP scripts on your site perform nearly or even completely identical tasks. In my experience with ASP, I’ve identified two distinct areas in which developers usually create several common scripts: form use and database access. Creating multiple scripts to do nearly the same thing is not only cumbersome, but also error-prone and far from maintainable. These two areas would benefit the most from extensive and intelligent code reuse.
This chapter, as its name suggests, deals with form reuse. Chapter 6, discusses techniques for code reuse in ASP scripts that utilize databases.
On a data-driven web site, forms are extremely useful tools that allow visitors to query, insert, delete, or update particular bits of data from a database. Without forms, data-driven web sites are essentially useless.
When creating forms for an ASP web site, the developer will usually follow these steps:
Create an HTML form with the proper form fields, complete with client-side form validation.
Create a form-processing script and add the needed code.
Add server-side form validation code to the ASP page created in Step 2.
In this chapter, we’ll look at ways of automating Steps 1 and 3, which are common to all forms throughout a web site. Step 2, of course, will be different depending on the form’s intended purpose. However, if we are creating administration pages for use in updating, deleting, or inserting records into a database, we may be able to generalize Step 2. Chapter 6 focuses on reuse of this kind.
Before we jump into a thorough discussion of form reuse for Steps 1 and 3, it is important you have a solid understanding of forms. Specifically, it is important you understand what forms are, the HTML needed to create them, and the ASP code used to process their results. In case you are a bit rusty, the next section provides a quick review of form use.