ASP Primer: Forming Up
Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js
Request.Form: Getting the Info
Now that you have had your refresher course on form elements, we'll jump into the ASP way of processing those forms.
While we discussed the different form elements in the last section, we didn't discuss how to define the form itself. To define a form on your page you will need to use the <FORM> and </FORM> tags. Within the <FORM> tag you will want to be sure to add these items:
<FORM METHOD="post" ACTION="myprocess.asp">
When setting the action you first need to determine how you want to handle processing of the form. You can approach it in two ways. You can either call the same page that has the form on it or call a new page. Here are some advantages and disadvantages to each approach:
Same Page - Calling the same page will allow you to have all your code in one centralized location. This method is often easier to read and debug because all of your references are in the same location. It's biggest disadvantage is that it makes for a much larger page and can cause a delay in response.
New Page - This method componentizes your processes. By separating your form page from your processing page you will generally have a faster response. It also has the added benefit of being able to use the same processing page for more than one form. It's only drawback is that you might have to jump around between multiple pages to track down bugs.
So, how do you get the user's information from the form?
That's where Request.Form comes in. It works very similarly to Request.QueryString. To illustrate how it works I'll give you this week's practical example:
<% Option Explicit %>
<TITLE>My Password Login Page</TITLE>
<FORM METHOD="post" ACTION="login.asp">
Please enter your password:
<INPUT TYPE="password" NAME="Pswd" SIZE="10">
<INPUT TYPE="submit" VALUE="Go!" NAME="SubmitButton">
Now, what you have here is your basic everyday form with one text box named "Pswd". You'll notice that we set the ACTION in the FORM tag to call the page "login.asp", which will be what we call this page. Since this will be a very small amount of code, we are going to combine our ASP and form on the same page.
If we were doing more complex or extensive coding, I would probably recommend using two pages, one for the form and one for the code. The rest of the elements in the example above are straight-forward HTML and should be familiar to you.
Now, here's our ASP code that will process the user's password:
Place this code between the <% Option Explicit %> and <HTML> above.
<% If Request.Form("pswd") = "password" then
Session("access") = "yes"
End If %>
In the code above we are checking to see if the password the user entered is correct and then sending them on to our secured section if it is. To achieve this we are using some ASP and VBScript that you have already learned in cooperation with some new stuff.
I threw you a bit of a curve on this one. You'll notice that each line doesn't have a <% and %> on it. It isn't necessary to use <% and %> on every line, so instead we use <% to begin our block of code and %> to signify the end of our code block. I waited until now to tell you about this so that you would have a chance to get used to using the ASP special delimiters (<% and %>) first.
First, we will create and set a Session variable called "access" equal to "yes". This is what we will use on our secured page(s) to see if a user is logged in or not. We'll get to that in a minute.
Second, we will send the user on to a new page called "securedpage.asp". This page can either be a single secured page or the welcome page to a whole secured section of pages.
That's really all there is to it. However, there are a few things that you need to understand about Request.Form. Request.Form will only return values on the page that was specified in the ACTION. If the user has moved beyond your processing page, their input on the form will be gone. In our example above, if you tried a Request.Form("pswd") on your securedpage.asp, you would always get an empty string returned ("").
The other very important item that you should realize is that the form elements can be very different in how they are handled. Here is a brief overview of how to handle each of the elements that we talked about earlier:
Text Boxes - Whether it's a simple or masked text box, Request.Form will return the user's input.
Text Areas - This works exactly the same as the Text Boxes. If you give Request.Form the name of the Text Area, it will return what the user input. If you set a default value for the Text Area and the user made no changes, you will get the default value back.
Radio Buttons - These are a bit different. With Radio Buttons, you will need to use the group name. When you give Request.Form the group name it will return the VALUE of the button the user selected. The VALUE is what will tell you which button was selected so that you can properly process the user's input.
Check Boxes - With Check Boxes, you will have to check each individual check box to see whether it has been checked. Remember, Check Boxes each have a unique name, so it can be quite cumbersome to check dozens of check boxes from a form. Request.Form will return the VALUE that you set for each check box. You can use the Check Box VALUE to store a simple indicator that lets you know it was checked, like the word "ON", or place a VALUE that is a bit more useful like a special ID number.
Drop Down Lists - By default, a Drop Down List will only allow for one selection. Request.Form will return the OPTION name that the user chose.
We will show you additional examples of these form elements in action as we progress through this series.
Now, there is one more little item to take care of to finish off our practical example we started above. For each page that you want to be secured, add this little bit of ASP to the top of the page:
<% Option Explicit %>
<% If Session("access") <> "yes" then
End If %>
The code above will check the Session variable that you created to see if the user is indeed logged in. If they are not, they are redirected back to your login page so that they can enter the password.