HomeASP.NET Programming an ASP.NET AJAX Server-Centric...
Programming an ASP.NET AJAX Server-Centric Based Online Shopping Website
Welcome to the third part of an 11-part series. From now on, we will set our feet on the long journey of doing all the related programming work. However, to make things simple we will leave out the discussion about the general database access modules. Instead, we will go directly into the registration and login-related programming.
Contributed by Xianzhong Zhu Rating: / 10 December 12, 2007
Just as with a typical web application the first step is to register, we'll start our web page design by preparing the registration and login processes.
Registering the User Info
First of all, we should make it clear that the registration discussed here is mainly aimed at common users/customers, i.e. the role of all the newly-registered users is the same: "Common Customer" (with a RoleID of 3). By the way, when we get into a later discussion of background management, we will build some special web pages to manage the role data.
Interface Design
The following Figure 6 corresponds to the design-time snapshot of the "Register.aspx."
Figure 6—the design-time snapshot for registration
Since this is the first time in this article series that you'll be authoring an ASP.NET AJAX server-centric based page, I'm going to give you some details in constructing such a page. At the very beginning, we must drag the server-side control ScriptManageronto the topmost part of the page. The ScriptManagermainly takes the responsibility of sending the necessary JavaScript files and Web Service proxy in the run time to the client-side browser. In a word, it serves as the center of the whole ASP.NET AJAX architecture. And also, in a common ASP.NET page, the recommended position in which to anchor ScriptManageris just after the <form> element is declared, as is indicated in the following code snippet:
As the foundation is laid, you can then safely drag other ASP.NET AJAX controls onto the page, which also include the controls provided by the ASP.NET AJAX Toolkits.
As Figure 6 indicates, we have leveraged three Extender controls out of the ASP.NET AJAX Control Toolkit here: TextBoxWatermarkExtender, PasswordStrength and ValidatorCalloutExtender. TextBoxWatermarkis an ASP.NET AJAX extender that can be attached to an ASP.NET TextBox control to get "watermark" behavior. When a watermarked TextBox is empty, it displays a message to the user with a custom CSS style. Once the user has typed some text into the TextBox, the watermarked appearance goes away. The typical purpose of a watermark is to provide more information to the user about the TextBox itself without cluttering up the rest of the page.
The second control mentioned above, PasswordStrength, however, is an ASP.NET AJAX extender that can be attached to an ASP.NET TextBox control used for the entry of passwords. The PasswordStrengthextender shows the strength of the password in the TextBox and updates itself as the user types the password. The indicator can display the strength of the password as a text message or with a progress bar indicator. The styling and position of both types of indicators is configurable.
Finally, the third control, ValidatorCallout,is also an ASP.NET AJAX extender that enhances the functionality of existing ASP.NET validators. To use this control, add an input field and a validator control as you normally would. Then add the ValidatorCalloutand set its TargetControlIDproperty to reference the validator control.
The following Figure 7 shows the running time snapshot relating to the above page.
Figure 7—the running-time snapshot when users register
For brevity, we’ve only "decorated" three ASP.NET TextBox controls in Figure 7 with the above three extender controls. Any user who has had a few desktop application experiences will appreciate this kind of web application design mode—it drastically enhances the user experience!
When the registering user clicks the "OK" button the related click event handler SureBtn_Clickis triggered. Note herein we temporarily save the registration information into one of the important browser-side variables, namedSession, and then redirect the user to another page, "CommitRegister.aspx," where he can really submit his registration information to the remote web server.
For the convenience of using Session, we’ve defined a helper class, UserInfo, which encapsulates all the detailed data that he just entered. The following code gives more detail:
public class UserInfo{
public string UserName;
public string RealName;
public string Password;
public string Address;
public string Email;
public string Phone;
public string Mobile;
public string Remark;
public readonly static string UserIDString = "USERINFO";
}
Let’s examine the code of the above event handler:
Surely, there’s nothing peculiar, is there? Now let’s continue looking at the page on which the registration is finished. The following Figure 8, shown in the next section, gives the related runtime snapshot of the "CommitRegister.aspx" page.
Figure 8—the running-time snapshot for users to finally submit their registration info
From the above figure, we can see that all the information displayed here is just the same as that entered in the previous step. When the user clicks the "OK" button the related user information will be saved finally into the server-side SQL Server database, while when he clicks the "Previous" button he will once more be navigated back to the previous page, "Register.aspx."
In addition, there are also two things worth mentioning. First, we use Firefox instead of IE to test the page; and second, the phone call number format follows the form "nnn-nnnnnnnn" while the mobile number format follows the form "13nnnnnnnnn" (refer to the downloaded source code).
Finally, let’s delve into the related submitting code, as follows:
Response.Write("<script>window.alert('Register failure! Check your register info again.')</script>");
}
}
First, we judge whether the user has populated his registration information, or else we do nothing. Next, we obtain the user registration information via the browser variable Sessionand save it into a UserInfoinstance. Then, by invoking a member function, namelyAddUserof the instance of class Userthe details of the user registration are persisted into the back-end database table User. Finally, we display the information of the operating result via the typical "Response.Write" invocation. That’s all.
When the user clicks the "Login" button on the main page of the sample (i.e. "Product.aspx"), another page named "UserLogin.aspx" is navigated to for him to log into the system, where he should enter his username and password correctly, or else the related improper login information will displayed before him. Note the login and logoff pages are all traditional ASP.NET pages with nothing ajaxified.
Author's Note: because the online shopping demonstration is pretty long and features somewhat complicated logic we choose to leave the article space mainly for ASP.NET AJAX related topics and the important inner workings of the application. Therefore, not every part of the sample that should have been ajaxified has been ajaxified. The design of the two pages herein exemplifies this.
Okay, now let’s as usual take a first look at the design-time snapshot of the login page in Figure 9.
Figure 9—the design-time snapshot of the login page
To force the user to enter the login information we have simply utilized two ASP.NET server controls, includingRequiredFieldValidator. Now, let’s check out the related programming to see what happens when the user clicks the "OK" button to try to log into the system.
ShowMessage("The username/password you just entered is invalid, please try again!");
}
}
Here, we first simply verify whether the username and password are empty, then by fetching the original user information, verify whether the information entered is valid or not. When the user fails to fill in the username or his password he will be shown the related error prompt. With the user successfully logging in, the current login information is temporarily saved into the Session variableand the user will be redirected to the product viewing page, namely "product.aspx." Here we achieve verification of the information by invoking the member function GetUserLoginof class Userto get the user's original information.
As is well known, in really good web applications the "logging off" function is a must have. With the log-off function supported, the user can more safely use the application. For example, if the browser supports the Sessionand the user chooses to let the browser remember his login information when the user first logs into the system, then when he simply closes or leaves the current application the personal, private data he entered will still be kept in the browser’s variables. This is very dangerous!
In fact, the log-off page is pretty simple. First, there is nothing on the "UserLogoff.aspx" page. Second, only the Page_Loadfunction in the "UserLogoff.aspx.cs" page is coded, as is listed in the following:
As you’ve seen, the really important private data within Sessionis cleared. And finally, the user is redirected to the "Default.aspx" page which does nothing but redirect the user to the main page, "Product.aspx."
ASP.NET 
/ 10 
Completing an ASP.NET AJAX Server-Centric Based Online Shopping Website/Building_ASP.NET_AJAX_Server-Centric_Shopping_Website(3)_html_42a478ed.png)
/Building_ASP.NET_AJAX_Server-Centric_Shopping_Website(3)_html_m261b432c.png)
/Building_ASP.NET_AJAX_Server-Centric_Shopping_Website(3)_html_m229734ad.png)
/Building_ASP.NET_AJAX_Server-Centric_Shopping_Website(3)_html_m3e79bb08.png)
