Using Personalization Creating user profiles Retrieving, changing, and saving profile properties Using validation controls Using the Forms Designer

Introduction When you configure your Web site to support membership, VWD automatically creates database tables to store information about user accounts. However, it creates only the bare-minimum number of fields needed, such as User Name, Address, and Password. If you want to store more information than that about each user, such as name, address, and phone number, you must define profile properties. The basic idea in VWD is this: Every authenticated user has a profile that contains information about that user. In code, you can use the simple syntax Profile.propertyname to get, or store, information about each user. The keyword Profile (with an uppercase P) always means “whichever user happens to be viewing this page.”

Setting up Profiles For each person who creates an account on your Web site you should include at least the following data: FirstName LastName Address1 Address2 (optional second line of street address). City StateProvince ZIPPostalCode Country

Setting up user profiles To define user profiles, you need to manually edit the Web.config file in the root of your Web site: Open Web.config for editing by just double-clicking its icon. Typically you’ll see that filename located near the bottom of Solution Explorer. Just above the closing tag, type and press Enter. A closing tag is added automatically. With the cursor placed between the and tags, type: and press Enter. Once again, the closing tag is entered Between the and tags you need to type a tag for each property you want to define using the following syntax: where propertyName is the name of the profile property.

Changes in the Web.config Type the following: 

Your Web.config should look like

Another Sample of the Web.config

How to let Users enter their properties The whole purpose of creating profile properties is to store information about users (site members). You want each user to type in his or her own profile properties. To do so, you need to provide users with a fill- in-the blanks form. A form is basically a Web page with controls for entering and editing data. To create a Web form for entering profile properties, just create a new, empty.aspx page (For Example CreateProfile.aspx) to let users enter profile information in their own accounts. Steps In Solution Explorer, right-click the folder in which you want to store the new page and choose Add New Item. Good idea to put it in the MemberPages folder. In the Add New Item dialog box, click Web Form. Enter a filename for your page (CreateProfile.aspx). Click the Add button. If you opted to use a Master Page, choose your master, and then click OK.

Make the page to look like:

Names for your VARIABLES

Typing code to an event Add labels and textboxes Add a button Fix their positions by using Layout  Position  Absolute Double click on the button

Determining where to put the profile information The next thing to consider is when users enter profile information. You can provide a link to the page from any place you want (though a good time to grab users is right after they finish successfully creating their individual user accounts). If you used a CreateUserWizard control to let users set up accounts, the job is easy. You just set the ContinueDestinationPageURL property of the CreateUserWizard control to the CreateProfile.aspx page. Open the page in design view, click the control to select it, and then scroll through the (lengthy) set of properties until you get to ContinueDestinationPageURL. There you should click the property, click the Build button, navigate to the CreateProfile.aspx page, and click OK.

Example

Think About Security Think about Web site security the whole way through the above scenario. You don’t want anonymous users to have any access to profiles, so put the CreateProfile.aspx page in the MemberPages folder. That way an anonymous user can’t get to that page. The only way to get to that page is by first successfully creating a valid user account. The word “successfully” is key there. I wouldn’t want people to sneak around setting up accounts. But that’s not going to happen; only users who successfully create an account can reach the ContinueDestinationPageURL. That restriction is built right into the logic of the CreateUserWizard If you’re going to allow users to enter profile information, you’ll also have to let them change their own information. We haven’t done anything about that yet. But you can do so pretty quickly.

Letting users edit their profiles You’ve only created a form that can store information in a user’s profile.You haven’t come up with a means to retrieve a user’s profile properties. If we want users to edit their own profiles, we need a page that can retrieve the profile information, show it on a form for the user to view (or edit), and if need be, send any changes back to the database. Getting data from the profile to the text box is just the opposite of getting data from the text box to the profile. That is, rather than making the profile property equal to the text box’s text, you make the text box text equal to the profile property. For example, to copy the user’s FirstName profile property to a control named txtFirstName, the C# statement is: txtFirstName.Text = Profile.FirstName;

Letting users edit their profiles  Continue You could whip this profile-retrieval page together quickly just by making a copy of CreateProfile.aspx and renaming it to EditProfile.aspx. To do this, open the EditProfile.aspx page, then double-click some empty space on the page background (or the content placeholder). Or you can just double-click EditProfile.aspx.cs in Solution Explorer. Either way, the code-behind page opens. You want the profile properties to be loaded into the page as soon as the page opens so the user sees their information and can make changes. To execute code as soon as a page opens, put that code in the page’s Page_Load event handler. There’s just one catch. With ASP.NET programming, every time a user does something on your page, a postback gets sent to the Web server. The postback causes the Page_Load event handler to execute again — which is fine in some cases — sometimes (as in this situation) the Page_Load code should execute only when the user first opens the page — not every time they click a button on the page.

Letting users edit their profiles  Continue SO ADD THE CODE :

Where are profile properties stored? The profile properties are stored in the same database as the rest of the membership stuff —the database you see when you click the Database Explorer tab instead of Solution Explorer. Specifically, the profile properties are stored in the aspnet_Profile table. But the profiles aren’t stored in a traditional manner, so you don’t want to go rummaging around in that table unless you really know what you’re doing. NOTE : If you put your CreateProfile and EditProfile pages in a protected folder, don’t be surprised if your login page opens when you try to view either one in a Web browser. When you’re in a Web browser, you’re just another user. Like everyone else, you have to log in to a valid user account before you can access any page in your site’s protected folder(s).

Using Validation Controls The sample forms we presented earlier have one weakness: They accept anything the user types into the boxes. In fact, they accept the form even if the user leaves every text box empty. That might be okay if you don’t want to force users to enter personal information. But if getting profile data from users is important, you may have to reject empty fields or fields that contain meaningless data. The ASP.NET validation controls, available in the Validation section of the Toolbox, make it easy to verify form data. To use a validation control, you first need a place to put it on your form. You’ll want to put it near the control you’re validating, because the control will display an error message if the user’s entry isn’t valid.

Properties of Validation Controls Most validation controls have certain properties that must be set in order for the validation to work. The main properties are: ControlToValidate: Specify the name (ID) of the Textbox control that should be validated. Display: Choose Dynamic so the error message takes up no space on the screen unless a user’s entry fails the validity test. ErrorMessage: Any text you type here is used in a ValidationSummary control (if any) on the current page. This is not the error message that appears near the control. Text: Whatever you type here appears next to the control, but only if a user’s entry fails to pass validation. It can be a simple asterisk (*) or a more descriptive message such as Required Field!.

RequiredFieldValidator The most commonly used validation control is the RequiredFieldValidator, which prevents users from leaving a text box empty. It’s super-easy to use: You just drag the control to your page, and then set its ControlToValidate property to the programmatic name (ID) of the control that you don’t want left blank. Example: Add a third column to a table, and then drag a RequiredFieldValidator control to the cell to the right of my txtFirstName Textbox control. Set the ControlToValidate property to txtFirstName to ensure that the text box would not be left blank. Set the Display property to Dynamic, and the ErrorMessage to First name required. Set the Text property to an asterisk (*) — which reduced the size of the control to an asterisk. You can see the control selected, in the upperright table cell, in the following figure

RequiredFieldValidator  Continue

In a Web browser, those properties play out as follows: When the page first opens, the validation control is there but invisible. If the user clicks the Submit button and the text box is empty, the validation control shows its Text property (here it’s a red asterisk). The ErrorText is displayed in a ValidationSummary control — provided that you’ve added one to your page a “ValidationSummary” section (See in a minute). You can add as many validation controls to a page as you need to ensure quality data entry.

RangeValidator The RangeValidator lets you check an entered value to verify that it falls within some range of acceptable values. It’s the same idea as other controls in that you drag it to the page and set its ControlToValidate property to the name of the control you want validated. Then you set the Maximum Value and Minimum Value properties to define the range of acceptable values for the control.

RegularExpressionValidator A regular expression is a symbolic way of defining complex validation criteria. You can do things like validate an entry against a pattern of characters, or add complex “or” logic to a validation control. The language for creating regular expressions is extensive and beyond the scope of this course. But there are some ready-made ones that you can use without studying the whole language of regular expressions. Check us/cpguide/html/cpconcomregularexpressions.asp.

CompareValidator Use the CompareValidator to check a text box entry by comparing it to a known value or the contents of another control. The most common use of this is when having a user enter a new password twice. Use a CompareValidator to compare the contents of the two controls, and reject both entries if they don’t match. Here’s how to use one: Drag a CompareValidator control to your form and drop it there. Check the new control by setting its ControlToValidate property to the name of the control. Use the control to make a comparison of contents. To compare your control’s contents to those of another control, set the ControlToCompare property to the name of the control to which you’re comparing the current control. To compare the entry to some other known value, set the ValueToCompare property of the control to the comparison value.

CustomValidator Use a CustomValidator if none of the other validation controls can do what you need done — and you also happen to be a skilled programmer. If that’s your thing, here are your steps: Drag a CustomValidator control to the page. Set the control’s ControlToValidate property to the name of the control you want to validate. Switch back to your form. Outside the Properties sheet, double-click the CustomValidator control you dropped onto the page. The code-behind file for the page opens with a new CustomValidator1_ServerValidate procedure all ready and waiting for you to type in your code. Write your validation routine, close and save both files, then view the page in a Web browser to test it out.

ValidationSummary The ValidationSummary control displays a summary of all failed validations that occurred on the form. All you have to do is drop it on the form. You don’t even need to change its properties. In Design view, the ValidationSummary is just a placeholder showing no useful information. In a Web browser, it initially is invisible. After the user clicks the Submit button, it lists the ErrorMessageText of each control that failed validation. It’s simple to use, and handy for users.