Article | Topic: ASP Server-Side Scripting

Online Portfolio | Search Optimization | Archive
Web Design | Custom Scripting | Web Database | E-Commerce | Search Optimization | Flash Web Design | Consulting
Template 'Tuning' | Template Designs
Desktop Solutions | Database Solutions | Automation Solutions | Integration | Project Solutions
Flash | 3D Design | 3D For The Web | Animation | Graphic Design | Conceptual Design | Reality Modeling
E-Learning | Disc Media | Business Graphics | Marketing Media | Custom Documents
Articles | Price Quotes | Site Map | Search Site | Web Links | About Neo•Paradigms | Contact Us
Anatomy of a Dynamic Web Page

Part 1: Gathering User Input

This article is not meant to teach the reader how, specifically, to code a particular task. The intent is to introduce the concepts and the thinking behind the code. With a reference book - or even a web based tutorial - open the reader can find the syntax and calling methods to write the code required. What most tutorials fail to identify is the reasoning behind the choices a developer makes when writing a solution. At the conclusion of this article the reader will have an understanding of the development task, the choices that come into the design process and a basic idea of what the code should accomplish and why. Let's take a simple and common task as an example of dynamic web development;


The Humble Contact Page.

The first step in creating our page is to define the work to be done. We will not concern ourselves with pretty backgrounds ...alright, so maybe that's funny given the nature of this web site's pages but let's just get past that... we will confine our discussion to the bones of design. Our contact page will do the following

  • Collect user responses in a form
  • Collect browser data fpr statistical use
  • Save the data in a database
  • Send an email with the user's responses
  • Redirect the user afterward to a new page
Not terribly complex but plenty of opportunity to put ASP to work.

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

                       About Us | Site Map | Privacy Policy | Contact Us | ©1992 - 2005 Neo•Paradigms