Register.aspx Page

Description:   The Register.aspx page enables users browsing Adventure Works Cycles to register as a customer.

Implementation Notes:  The core Register page logic is encapsulated entirely within its RegisterButton_Click  event handler.  This event handler is called on the server when a user clicks the Submit ImageButton on the client. 

RegisterButton_Click Event Handler:   This event handler uses the AddCustomer method of the CustomersDB class to add a new customer into the Adventure Works Cycles database.  This method internally uses the usp_CustomerAdd  stored procedure to insert a new customer record into the Adventure Works Cycles database.

After the new customer record is added, the RegisterButton_Click event handler performs four important actions:

  1. It migrates any items stored within a browser's temporary shopping cart into a permanent shopping cart that is keyed off of the customer's new unique CustomerID.  This ensures that the shopping cart items are not lost if the customer's browser crashes.  It also enables customers to suspend their shopping experience -- closing their browser or powering off their machine  -- then resume it days later, or on another machine. 
  2. It sends a custom "AdventureWorks_FullName" personalization cookie to the client that contains the full user name of the newly registered user.  The home page of the Adventure Works Cycles application -- Default.aspx -- will look for this cookie to optionally personalize a welcome message for the user the next time they visit the page.
  3. It invokes theSetAuthCookie()static method on the CookieAuthentication class.  This built-in ASP.NET method issues a MAC-encrypted cookie authentication ticket to the browser client that identifies their authenticated username of the customer.  In Adventure Works Cycles, we use the CustomerID value returned from the CustomersDB.Login method as the username identity of the client.  This is passed as the first argument to the SetAuthCookie() method.  On subsequent requests to the application we are able to gain access to the CustomerID user token through the built-in User.Identity.Name property of the ASP.NET page. 
  4. It redirect the browser to the Demographics.aspx page -- where users can then optionally enter information about themselves.

Validating User Input:  The page requires that users enter a name and email address. If you look at the source for the LoginButton_Click event handler, you'll see that there is no input validation code. Instead, we use the built-in ASP.NET validation controls, which enable you to declaratively specify validation constraints on any input control.

ASP.NET comes with built-in validation controls to handle almost any validation requirement: the RequiredField, CompareValidator, RegularExpressionValidator, RangeValidator, and CustomValidator controls. The validation control architecture is extensible, so that other situation-specific controls (ZIP code validators, country code validators, etc) can also be developed by third parties.

You can put a validation control anywhere on a page and declaratively link it to a target input control using the validator's ControlToValidate property. You can optionally specify a Text property that displays in place of the validation control if the input data fails the validation test. If necessary, you can use multiple validators to chain validation logic for a single control (for example, a field is required and must meet a specified pattern).

If the page is displayed in a browser that supports EcmaScript 1.2 and the Dynamic HTML (DHTML) 4.0, the validation controls can perform client-side validation, which provides immediate feedback to the user.  The validators also perform their check in server code, so if the browser does not support DHMTL, or if client-side scripting is disabled, the validation check is still performed. No code changes are required to enable either scenario -- all logic required to handle the checks on both basic and DHTML-compatible browsers is built into the controls themselves.

If you are using validation controls, your server code can determine whether the user's input passed the check by testing the IsValid property of the validation control. Additionally, you can check the page's IsValid property; this property is an aggregate of the IsValid properties of all the validators on the page. If any one validation has detected a failure, the page's IsValid property is set to false.

That's how the Register page works. Only if all controls on the page are valid will we go ahead and add the new customer. If one of the input fields is invalid, then the page will simply be redisplayed again, with the validation controls automatically taking care of displaying the appropriate error message to the user.