User Registration - Part 3

Although we have completed our script, we still have a lot of things to do before our application is complete. First, we will have to convert the registration page into an ASP script to incorporate code into it that will customize the display for a new user, a returning user, or a user who has chosen a duplicate ID. Code to print the post-registration success message on the florist.html page should also be added.

Open the register.htm file in Visual Web Developer. Do not close the saveuser.asp file. Save the registration.htm file as registration.asp using the 'File -> Save Registration.htm as' menu item. We may now add ASP code to the registration file. First, let us consider the three scenarios that will cause the page to load.

A new user may click on a registration link - The display and functionality of the registration.htm (now registration.asp) file is fine just as it is for a new user.

The registration page may be reloaded from the all-hidden-fields form in saveuser.asp because the new user entered a duplicate login. In this case, a message asking the user to choose another login ID should be displayed. In addition, all the other form fields should be preloaded with the data the user entered the last time around.

An existing user may navigate to the registration page in order to change his or her details. In this case, a customized welcome back message should be displayed. A hidden input control named 'operation' containing the value 'update' should be added to the form (this field helps us determine if we are processing a new user's information or an existing user's information in saveuser.asp). The login and two password entry fields should not be displayed; other fields should be displayed preloaded with existing values from the database.

We can use the "login" and "loginduplicate" session variables to output appropriate HTML. The following code goes into the very start of register.asp. It is easy enough to understand. Upon login or registration, the "login" session ID is set to the login ID of the user. If this variable is not empty, we know that this is a modification request. We retrieve the user's row from the database and set all the variables declared in the first line to the values from the database. Afterwards, the record set and the connection are closed. Note that we replace "`" with single quotes to display data exactly as the user had entered it (we substituted "`" for single quotes before entering data into the 'users' table.). The split function is used to get separate strings for the birth month and birth year. We also set a variable called 'operationtype' to 'update' to keep track of the fact that we are displaying the modification form.

<%dim lname, fname, phone, gender, favflowers, message
if (Session("login") <> "") then

        login = Session("login")

        set conn=Server.CreateObject("ADODB.Connection")
        conn.Mode = 3
        conn.open "florist","",""

        set rs = Server.CreateObject("ADODB.recordset")
        rs.Open "SELECT * From users where login like '" & login & "'", conn

        if not rs.eof then
                lname = replace(rs("lname"),"`","'",1,-1,1)
                fname = replace(rs("fname"),"`","'",1,-1,1)
                phone = rs("phone")
                gender = rs("gender")
                favflowers = rs("likes")
                message = replace(rs("message"),"`","'",1,-1,1)
                birthday = split(rs("bday"),"-",-1,1)
                bmonth = birthday(0)
                bday = birthday(1)
                operationtype = "update"
        end if

        rs.close
        set rs = nothing
        conn.close
        set conn = nothing %>

The 'else' loop checks if the "loginduplicate" session variable is set. If so, we know that we are tackling a duplicate login display. In this case, we simply load all of the user's entries for the other fields into the variables declared in the first line of code (see the previous section). The values come from the form that was submitted in saveuser.asp.

<%elseif(Session("loginduplicate") <> "") then
        lname = request.form("lname")
        fname = request.form("fname")
        phone = request.form("phone")
        gender = request.form("gender")
        favflowers = request.form("likes")
        message = request.form("message")
        bmonth = request.form("month")
        bday = request.form("day")
end if%>

Javascript functionality should be changed to reflect page functionality. For instance, if we are displaying the modification screen, the validate() function should not contain validations for the login and password fields. These fields do not even exist in the version of the registration form displayed for modification! So, we will have add ASP code in the validate() function as follows:

function validate()  {
        <% if operationtype <> "update" then %>
        validField = /^[A-Za-z][\w\-]{5,}$/;
        loginStr = document.forms.register.login.value;
        if (validField.test(loginStr) == false)
          {
                  alert("Login Name has to start with a letter, contain only alphabets,
                  numbers, underscore, or hyphen and has to be at least six characters in
                  length");
 
                  return false;
      }

        validField = /^[\w\-]{6,9}$/;
        passwordStr = document.forms.register.password1.value;
        if (validField.test(passwordStr) == false )
        {
           alert("Password can only contain alphabets, numbers, underscore, or hyphen
           and has to be between six and nine characters in length");
           return false;
        }

        if(document.forms.register.password1.value !=
        document.forms.register.password2.value)
        {
                alert("Passwords do not match - please enter same password twice");
            return false;
        }
        <%end if%>

The highlighted code checks if the display is for a new user or a user who has entered a duplicate login ID by examining the value of the 'operationtype' variable (the '<>' operator means the same as 'not equals'). The 'operationtype' variable would have been set to 'update' if the login session variable contains an ID. The sections of code that validate the login ID, the password, and check to see if the two password match are generated in the HTML document only if the request is from a new user, that is, if the operationtype field does not contain 'update'.