Article | Topic: ASP Server-Side Scripting

Forming the Form!

Right from the start ASP can become very useful and demonstrate efficient use. Although Internet Explorer has a commanding lead in the global install base, it is just good design to accomodate some of the other browsers in our design process. There are two ways we can do this; we can use JavaScript to get this information from the client browser and code each page for both the determination and the handling of the differences or we can use ASP and the host server to determine the information and handling. Which is better?

To answer this it is necessary to understand a little bit about resource usage in server versus client scripting. When client side scripting is employed the resources used are those of the end user browser and machine. Generally, processing a page at the client can be more efficient for tasks that are contained wholly inside the individual web page. A good example is the animation of page elements or form contents validation. It would be wasteful in both resources and time to load the page and then send and receive calls to and from the server to manipulate elements of a loaded page. Although we are dealing with how the end browser will display elements (based on coded differences) in this case server side scripting can and will be more efficient if used properly.

Proper use is the key phrase. Different types of functions use server resources differently. The task at hand, determining browser requirements and properties, involves querying the server for information carried to it by the request for your web page(s). Asking the server to tell you what it knows involves the heavier of the performance hits of server side scripting. If you ask the server to get this information for each page you send to the client that would be inefficient and poor design. If you think in terms of Every page on the host server coded the same way and all sending their data requests at the same instant you can see that the likelihood of slow response time, even timeout and loss of request, is very high.

Proper design, therefore, involves a mechanism not available in client side scripting; global variables and data. ASP and server side scripting allow you to get the information required all at once and store it until the end user leaves your site. So the correct choice to make here is to use ASP coding at the server side and collect the information in a single request when the user first hits your web site. The natural consequence of this is that you will also use server side scripting to read the stored information and predetermine the actions taken in the page construction before sending the page to the client. You will still have to code each page to check for the information but the check would be performed like this pseudo-code:

        If Global_variable_browser_type has been set
                build pages for Global_variable_browser_type
        Otherwise (this is the first page entered)
                Call Function to set all Global variables
                build pages for Global_variable_browser_type

Now we have built the Contact Form, noting any browser differences, and we're ready for user input.

Gathering Good Data From The User

One of the primary axioms in computing is: "Garbage In - Garbage Out." If your user enters garbage and it passes unchecked you will fill your database with nonsense. As mentioned previously. there are several methods available to make your form smart enough to validate the information in its fields. We are going to use server scripting to accomplish this. The process is simple. On submit of the form it merely reloads the very same page. There is no appreciable performance hit in doing this. The server gathers the user inputs and runs through your validation code. If the information is not validated then the server returns the page to the client machine for correction. A single page solution would include coding for error messages to be displayed in the page - as well as restoring the inputs so the end user does not have to start all over again.

In addition to verifying that all required fields are filled in - a typical validation test - it is also an extremely good idea to sanitize your users input. Check to see that all that is entered into your form is text - but not code. Maliscious people can take advantage of your form to try and run scripts and cause mayhem. You can prevent this easily by disallowing the angle bracket characters ("<", ">") for example.

If all the information is validated successfully the server can then move immediately to the next action coded. This is more efficient coding than having to return to the server from a validated page. We're already there! The next action we will perform is to store the user's information that we gathered in a database on your host server.

Anatomy of a Dynamic Web Page Part 2: Online Data access