AddThis Social Bookmark Button

Print

Five Tips for Designing Active Server Pages

by Scott Mitchell
09/14/2000

This tips list invites you to consider the big picture when building and designing Active Server Pages by focusing on how to plan for and create robust, reusable ASP pages--pages with fewer bugs, and pages that anticipate future changes. Here are Scott's suggestions, from basic to more advanced.

  1. Think First; Code Second. ASP developers are often so eager to start coding that they don't take enough development time to think about the programming challenge at hand. For example, developers are often asked to create pages that simply list the contents of a specific database table with a specific format. So, they just roll up their sleeves and hammer out the needed code. Before punching in any code, however, it's a good idea to first step back and think about the task and about what future assignments might be similar to the current one. Chances are, content in other database tables will also need to be displayed in different formats.

    Despite this possibility, you may still wonder why developers need to spend any time planning. After all, for such a simple task, writing the first line of code to the last may take only fifteen minutes to an hour. Why spend more time thinking about possible changes to the script, or ways to make the code reusable, or alternatives that may provide for more flexibility for altering the code at some future date?

    Because the time you spend contemplating and planning for future changes will be rewarded by hours of saved development time when (not if) future changes are needed to the script.

    If you create a generic, robust script, one that easily displays any database table based on a QueryString parameter, and one that also displays the data in any sort of style or appearance, you will save yourself many hours on future revisions, or on creating new yet similar scripts. Creating such a robust script obviously takes more planning time (and a lot more initial development time) than would simply creating the database display script mentioned earlier. However, you save development time whenever the robust script is used for a new table or with a new display style. Furthermore, as I'll discuss in Tip 2, the robust database script will prove less buggy than the other, more basic script. These two factors alone save immeasurable amounts of development and debugging time.

  2. Write Less Code. This tip is vital to creating large Web applications and is my First Axiom of Programming. (My Second Axiom of Programming is discussed in Tip 3). The logic for this axiom is quite simple. Obviously, bugs are produced by writing code, and the more code you write the more bugs you'll get. And, clearly, the faultier the application, the more debugging time it requires.

    Of course, this does not mean one should produce software with fewer features or less options simply to write less code. It means, rather, that developers should create code that can be reused. For example, let's say you were asked to create a server-side form validation routine for a specific form in a specific HTML page. You decide to build a generic server-side form validation class to handle not just this specific form for this specific HTML page but a server-side form validation class that could be used to validate many different types of forms on many different HTML pages.

    This robust form validation code would obviously contain much more code than a simple, specific form validator for the specific form/HTML page pair. Over time, however, when new server-side form validation routines are needed for other forms on other HTML pages, you would't need to create them because you had already designed a generic form validation routine. That's where the savings in development time and, ultimately, debugging time comes into play.

    This leads nicely into Tip 3....

  3. Reuse, Reuse, Reuse. The more often a piece of code is used, the fewer bugs it will contain. A block of code can be thought of as a black box that accepts a set of inputs and produces an output. For a given set of inputs, the output can either be correct (bug-free) or erroneous (buggy). The difficulty in debugging any chunk of code comes in testing, or trying to test, all of the possible inputs.

    When a piece of code is put into production, there is no guarantee that it is 100 percent bug-free. In fact, rarely is any production code free of bugs. The reason production code is not 100 percent bug-free is not because of lazy testers; it is because there are far more sets of inputs to be tested than there is time. When code starts being used in a production setting by hundreds, thousands, or even millions of users, the wide range of inputs are quickly tested.

    A piece of code that has been thoroughly used and does not have any hidden bugs is much more likely to be bug-free than a piece of code that hasn't been used as often. Simply put, when a block of code is released into the final product, it will soon face a number of tests that were not run by the developer during any testing or debugging of the code. I liken this to cars: What car would be safer to drive? A car that has been in production for years, which has had a low number of accidents, or a model that has just shipped?

    To keep the number of bugs in your ASP applications down, create reusable chunks of code, then reuse them. Over time, as you learn about new defects in the existing, reusable code blocks, fix those bugs and continue to reuse. Before long your reusable code block will be 100 percent bug-free and you can use it in future ASP pages with confidence that the code will not introduce any bugs.

  4. Know Your Tools for Reuse. The two most useful tools for reuse are classes and server-side includes. These are breifly discussed in the Introduction to Designing Active Server Pages.

    Server-side includes allow developers to create a set of reusable code-- either HTML, subroutines, functions, or classes--and group related reusable code in separate files. Then, when the services of these functions or classes are needed, the developer need only use a server-side include to automatically import the functions or classes. Server-side includes enable a developer to keep the reusable code separate from the ASP pages that utilize such code. This is handy since a change can be made to the reusable code, which is automatically reflected in all the ASP pages that imported the code using a server-side include. For a thorough article on server-side includes, be sure to read The Low-Down on #includeS.

    VBScript classes are, by far, the best tool for code reuse. Since classes serve to encapsulate a series of complex tasks into a simple, easy-to-use interface, they lend themselves naturally to designing robust solutions. If you are new to VBScript classes, I recommend you take a moment to read Using Classes in VBScript. VBScript did not support classes until Version 5 of the VBScript Scripting Engine. If you have a version predating this, you can obtain the latest (free) version of the VBScript Scripting Engine here. If you are unsure which VBScript version is installed on your Web server, read Determining the Scripting Language and Version.

  5. Encapsulate Complex Tasks Using Classes. Many repetitive tasks ASP developers find themselves coding again and again are relatively simple to code. For example, creating a set of Web-based administration pages for a database table is a common ASP task that is not overly complex. Many developers have had to create a Web-based tool to add, update, and delete records from a database table. If you want a complete, Web-based administration tool, adding these various forms is a task that must be repeated for each and every table in a database. If there are tens or even hundreds of database tables, this can lead to numerous ASP pages and oodles of code; and such code will also likely contain bugs, since it blatantly disregards Tip 2, the First Axiom of Programming.

    Obviously, creating a single, generic set of ASP pages that could be used as administration pages for all of the existing database tables and any future database tables would be ideal. However, difficulty arises in creating such a single, robust script due to the complex set of parameters needed for each database table's administration page. But if these complex input parameters are wrapped in a class, from the end-developer's standpoint, creating an administration page for any given database table would be as easy as instantiating a class, setting a few properties, and calling a method or two. By using classes, you can hide complex requirements, parameters, or tasks from other developers who use your classes, thereby making their programming easier, shorter, and more readable--all factors that lead to fewer bugs. For more information on this topic be sure to read Use Classes to Encapsulate Implementation Complexity.

Summary

In Designing Active Server Pages I look at how these methods can be used to create robust and reusable ASP scripts in real-world situations. I dedicated two chapters to building two robust classes that you can use in your ASP applications. The first is a reusable, generic server-side form validation class; the second is a robust, Web-based database table administration tool. Designing Active Server Pages lets you get your hands on some powerful, reusable scripts, and lets you apply the lessons you learn to your ASP projects. This will help you save development and debugging time by creating reusable and robust code. The book introduces several useful Microsoft and third-party components you can use to immediately enhance your Web site. And, finally, the book prompts you to think about how to develop all sorts of software applications--not just ASP applications.

Happy Programming!

Scott Mitchell is the founder and Webmaster of 4GuysFromRolla.com, one of the leading ASP resource sites on the Net. Scott is also the author of O'Reilly's Designing Active Server Pages, and Sams Teach Yourself Active Server Pages 3.0 in 21 Days.

O'Reilly & Associates will soon release (September 2000) Designing Active Server Pages.