Some Background on User Registration


Introduction.  Think of the different store sites you have used on the web.  Most of them have some capability for you to enter a profile that retains information about you from one visit to the next.  This profile is convenient for both you and the site managers.  It means you don't have to re-enter certain information each time you shop at the store.  it also means your information is more likely to be reliable for both your and the online store.

Most of these profile managers rely on your e-mail address and a password to uniquely identify you.  This is reasonable in most ways.  We will slightly modify what we have done previously to do the same.

It might also be the case that there are other situations where you have chosen to register your interests on the web.  While the details differ in each situation, there are going to be some overall functional similarities.  We will create a site that allows for the most typical sorts of operations.

  • users accessing the site
  • users adding their stats
  • users modifying their stats
  • users deleting their stats
  • users displaying the stats of other users

In the interest of creating a functioning template that makes use of all the basic HTML form controls

  • text boxes
    • including password boxes
  • drop down combo boxes
  • check boxes
  • radio buttons

I have made the inputs on the form a bit artificial.  But I figure it is more important that you see how to work with code for all of these sorts of controls.

I have also required some rather unusual inputs to make certain that you have to work with

  • text
  • numbers
  • boolean variables
  • dates
  • currency

You have probably noticed that

  • HTML is configured to deal with controls and inputs in one way
  • ASPs code has been configured to work with controls and inputs in another way
  • The DBMS has been configured to deal with data in another way.
    • you have seen this in Access
    • you will now see this in SQL Server

ASPs, as the middleware, are usually required to make certain the interactions between these programs appear seamless to the user.  This is not always particularly easy.  This is largely why I am setting up my template to consider so many possibilities.

Authentication.  We got into authentication of users in our HTML/ASP/Access implementation for individual users and for the administrators.  We will need to do the same for these developments.

The following table summarizes some of the characteristics and pages associated with each desired user functional capability.


  Pages Description Authentication
Home Page RegisterUserHome.html   none
Add Users AddUser.asp form page none
  AddNewUser.asp processing page none
Display Users DisplayUsers.asp processing page none
Delete Users DeleteUser.html form page obtains e-mail address and password
  DeleteUser.asp processing page checks validity of e-mail and password
deletes if found
Modify Users ModifyUser.html form page obtains e-mail address and password
  ModifyGetFeedback.asp processing page
form page
checks validity of e-mail and password
displays current stats if found
  ModifyUser.asp processing page checks validity if e-mail is changed
updates user stats


I have changed this somewhat to make it more based on e-mail addresses for identification.  There are also some other changes since we are going to be working with SQL Server and stored procedures.