Export (0) Print
Expand All
4 out of 7 rated this helpful - Rate this topic

ASP.NET Jumpstart: Establishing the Application and Page Framework

 

Bill Evjen
Reuters

November 2005

Applies to:
   Microsoft ASP.NET 2.0
   Visual Web Developer 2005 Express Edition

Summary: Learn how to build your own starter kit using Microsoft ASP.NET and Microsoft Visual Studio 2005 or Microsoft Visual Web Developer 2005 Express Edition. This is the third article in the ASP.NET Jumpstart series. (20 printed pages)

Click here to download the code sample for this article.

Contents

Introduction
Using a Page Template Throughout the Application
Building the Navigation System
Restricting Access to Parts of the Application
Working with a Personalization System
Applying Styles
Conclusion

Introduction

Welcome to third ASP.NET Jumpstart article, a four-article series that will run you through the creation of a complete application—from the beginning to the end. The first article in the ASP.NET Jumpstart series was an introduction to the completed starter kit showing you how to install and run the application. The second article discussed how to build the data tier of your application and to understand how the data source controls on your ASP.NET pages interact with the underlying data from the starter kit. This third article is going to continue to help you understand how the presentation tier of this application was built by looking at the establishment of the application and page frameworks that are used throughout.

The starter kit being built is called the Media Share Library Starter Kit. The Media Share Library Starter Kit enables you to easily create an application that allows registered users to present a collection of media items (such as movie DVDs, music CDs, books, and more) for other registered users to borrow. Users will be able to look through a library of items collectively held by the group using the application and request to borrow specific items from the registered owners of the items. The idea of the Media Share Library Starter Kit is to provide you with a framework that you can use to quickly organize a library collection that can be shared with a larger group of people.

As stated in the previous articles, the nice thing about the starter kit, whether you use it or not, is that it illustrates some of the more exciting additions to ASP.NET in this latest release—ASP.NET 2.0. The starter kit makes heavy use of master pages, the new code-behind model, new server controls, and more. However, the focus of this article is on the starter kit's use of some exciting and new ASP.NET foundation features you will find in ASP.NET 2.0, such as using master pages, as well as working with themes and navigation that are used in the pages of the application.

Let's start on our path of building up the starter kit's framework ourselves by first using the ASP.NET 2.0 master pages feature.

Using a Page Template Throughout the Application

One of the more exciting additions to ASP.NET 2.0 is the addition of master pages. Basically, what master pages provide is a way in which you can establish a page template that can be used throughout your application. Most individuals don't build each and every page of their application to be too different from one another. For this reason, you will find that many of the page elements of your applications will be the same from page to page. For instance, most pages seem to include a header, navigation sidebar, and a footer of some kind. If you are building your application using a template, you can place these common elements into the template, so there is no need to re-program these items time and time again as each page in the application is developed. Also, if you need to make a change to one of these common elements, when using a template, you only need to make one change for it to be reflected throughout the entire application.

Building the Master Page—MediaLibraryMain.master

OK, so templates make sense, but how do you go about this in ASP.NET 2.0? Creating a master page is as simple as creating a standard .aspx page. You can accomplish this from the New File dialog box. For the Media Share Library Starter Kit, the master page is given the name MediaLibraryMain.master (notice that instead of the standard .aspx file extension, the master page uses the .master file extension).

The MediaLibraryMain.master page has the following page directive at the top of the page, as shown in Listing 1.

Listing 1. The @Master page directive

<%@ Master Language="VB" CodeFile="MediaLibraryMain.master.vb" 
    Inherits="MediaLibraryMain" %>

As you can see, there isn't much difference between the @Master directive and the @Page directive. You will find many of the attributes to be the same.

Looking at the MediaLibraryMain.master page in Microsoft Visual Studio, you can view the page in the Design view, as shown in Figure 1.

Click here for larger image.

Figure 1. Looking at the Media Share Library's master page in the Design view

Looking over this figure, you can see that the Media Share Library's master page is pretty simple. There are only a couple of controls that are actually on the page. These controls and elements are what we want to appear on each and every page of the application. There is a header, navigation, a couple of links to log in to the application, a SiteMapDataSource control, and most importantly—a ContentPlaceHolder control.

The SiteMapDataSource control (which is at the bottom of the master page and is therefore not visible in figure 1) simply needs to be present on the page to be able to interact with the Web.sitemap file that is contained in the application. Connected to this .sitemap file is a Menu control that is used to display the navigation of the application. This navigation system is discussed later in this article.

The ContentPlaceHolder control is a specified area of the master page that states where any inheriting content pages can place their page data and information. Everything outside any ContentPlaceHolder controls that are contained on the page (as there can be more than one) is considered part of the page template.

The last control on the master page to really focus on is the LoginView control. This is a control that is tied to the application's membership and role management system. The LoginView control can display a couple of different views or sets of data to the end user. There is a view for authenticated users (users who are logged into the application in some manner), anonymous users (users who are visiting the application but have yet to provide credentials), and users who are not only authenticated but they are also contained in a specific application role (such as the Admin role). Let's review the LoginView that is used on the MediaLibraryMain.master page. This is presented in Listing 2.

Listing 2. Reviewing the LoginView server control

<asp:LoginView ID="LoginView1" runat="server">
   <AnonymousTemplate>
      &nbsp;<asp:LoginStatus ID="LoginStatus1" runat="server" />
      <br />
      &nbsp;<asp:HyperLink ID="HyperLink1" runat="server" 
         NavigateUrl="Join.aspx" Text="Join Today!"></asp:HyperLink>
   </AnonymousTemplate>
   <LoggedInTemplate>
      &nbsp;<asp:LoginStatus ID="LoginStatus1" runat="server" />
   </LoggedInTemplate>
</asp:LoginView>

In this case, we have a view for anonymous users and another for users who have logged into the application. The only difference between the two views is there will be a hyperlink to the Join.aspx page shown to anonymous users, pressing them to join in on the fun. Besides that, both views show a LoginStatus control, which will show a Login hyperlink to anonymous users and a Logout hyperlink to logged-in users. Next, we will take a look at using this master page.

Inheriting the Master Page—Creating Your Content Pages

Now that the master page is in place, this is not something that you can call up in the browser. The idea is that you will create a content page that will make use of the page template defined in the master page.

To accomplish this task, let's look at the creation of the Default.aspx page found in the root of the application. In Visual Studio, right-click on the project found in the Solution Explorer and select Add New Item from the provided menu. This will launch the Add New Item dialog box. From this dialog box, select Web Form. You will then be presented with a couple of options for the creation of this page. This dialog box is illustrated in Figure 2.

Aa479395.media3_fig02(en-us,MSDN.10).gif

Figure 2. Building a content page

The important items to select from the dialog box are whether or not put the business logic in a code-behind file (Default.aspx.vb), and whether or not to use a master page. The Media Share Library Starter Kit makes use of code-behind files throughout the entire application; it could, however, have easily been built with all the business logic code inline.

To turn the Default.aspx page into a content page, make sure the Select master page option is checked in the dialog box. This will cause a new dialog box to appear that allows you to select the master page you are interested in using (you can have multiple master pages in your application). This second dialog box is presented in Figure 3.

Aa479395.media3_fig03(en-us,MSDN.10).gif

Figure 3. Selecting the appropriate master page

After selecting your master page and clicking the OK button, the Default.aspx page will be created. It will appear a bit different than the standard .aspx pages that you might be used to seeing. First off, let's examine the @Page directive of this content page. This is presented in Listing 3.

Listing 3. The @Page directive of the content page

<%@ Page Language="VB" MasterPageFile="~/MediaLibraryMain.master" 
    AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" 
    Title="Media Share Library" Theme="Evjen" %>

From this directive, you can see that it is pretty standard except that you can tell it is a content page through the use of the MasterPageFile attribute. The value of the attribute needs to point to the location of the master page that you are interested in using.

In addition to this, another important attribute to pay attention to is the Title attribute. Yes, it is possible to declare the page's title directly in the master page between the <title> HTML elements contained on the page, but you can override this setting by defining the title of the page directly in the @Page directive using the Title attribute.

Finally, the last attribute to review (though it has nothing to do with master pages) is the Theme attribute. ASP.NET 2.0 pages can incorporate a centrally-managed style system called themes. This attribute simply points to the name of the theme that should be referenced for the generation of this page. Themes will be discussed later in this article.

Besides the @Page directive, the next item that really turns this Default.aspx page into a content page is seen in everything that is below the @Page directive declaration. Listing 4 displays this content.

Listing 4. The rest of the content page

<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" 
 Runat="Server">
   <fieldset>
   Welcome to the Media Share Library <!-- Content removed for clarity -->
   </fieldset>
</asp:Content>

Though not an absolute requirement, for each and every ContentPlaceHolder server control that is contained on the master page, there should be a corresponding Content server control on the ASP.NET page that inherits the master page. This means that since there is a single ContentPlaceHolder control on the MediaLibraryMain.master page (with the ID of ContentPlaceHolder1), in order to place content in this defined area you are going to need to incorporate a Content server control that points to this ContentPlaceHolder control on all the pages using this master page.

The Default.aspx does indeed use this master pag,e and for this reason: you will find the Content control, which is shown in Listing 4, contained on the page. The important attribute to pay attention to in this control is the ContentPlaceHolderID attribute, which points to the ID value of the ContentPlaceHolder control used on the master page (again, ContentPlaceHolder1).

Then, once you have the Content control in place on your page, you simply place all the server controls or HTML that you want to appear in the defined area on the master page within the opening and closing elements of the Content control. Placing server controls or HTML elements outside of this control is not allowed, and will result in your page throwing an error.

Also, remember not to place any opening and closing HTML page elements in the Content controls you use, as these are already defined in the master page (elements such as <html>, <head>, and <body>).

Building the Navigation System

The next step in building an application framework for the Media Share Library Starter Kit is to build the application's navigation system. As you saw from the early discussion on the use of master pages in the starter kit, a Menu server control is bound the application's navigation system for display to the end user. This Menu control, after being bound to the navigation system, is shown here in Figure 4.

Aa479395.media3_fig04(en-us,MSDN.10).gif

Figure 4. The Menu server control bound to the application's navigation system

Where is this information stored? Well, that is the exciting part of this all. ASP.NET 2.0 provides you with a way to store the entire application's navigation in a central location. Prior to this, many Web developers would place a navigation structure on each and every page of the application (usually just copying-and-pasting the navigation code from page to page). In this type of scenario, can you imagine what changes would be necessary to make to the navigation system for a huge Web application? Can you also imagine how error-prone this scenario really is?

By hosting the navigation settings centrally, a developer has only a single location to make changes and when changes are actually made, these changes are immediately reflected to each and every page of the application that is making use of this system.

The Media Share Library Starter Kit does make use of the ASP.NET 2.0 site navigation system. By default, it is all driven from an XML file—Web.sitemap. This file is shown in Listing 5.

Listing 5. The application's Web.sitemap file

<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0">
    <siteMapNode url="~/Default.aspx" title="Home" description="">
        <siteMapNode url="~/Library/Default.aspx" 
         title="Alerts &amp; Info" description="" />
        <siteMapNode url="~/Library/MainLibrary.aspx" 
         title="Main Library" description="" />
        <siteMapNode url="~/Library/MyLibrary.aspx" 
         title="My Library" description="" />
        <siteMapNode url="~/Library/EnterMedia.aspx" 
         title="Enter New Media" description="" />
        <siteMapNode url="~/Admin/Default.aspx" 
         title="Admin" description="" />
    </siteMapNode>
</siteMap>

There isn't much to this XML file. It is pretty simple, as you can see. A Web.sitemap file is made up of <siteMapNode> elements, and how they're nested determines the application's navigational structure. There can only be a single root page defined in the document (in this case, the Home page, Default.aspx). Beyond the Home page, the rest of the nested links point to pages in the main library and a single page for the site administrator.

With this XML file in place, you can now start working with it in your application. This is done by placing a SiteMapDataSource control on the pages on which you are going to use this navigational data. For us, the only place this occurs is on the master page, as discussed earlier. The master page of this starter kit, MediaLibraryMain.master, includes this data source control. You don't need to manually bind the data source control to the Web.sitemap file by adding any specifying attributes. Instead, the SiteMapDataSource control will bind to this XML file automatically on your behalf.

With a SiteMapDataSource control in place, it is then rather simple to use the Menu server control to display the application's navigation system using the DataSourceID attribute, as shown in Listing 6.

Listing 6. Binding the Menu server control to the SiteMapDataSource control

<asp:Menu ID="Menu1" runat="server" DataSourceID="SiteMapDataSource1">
</asp:Menu>

To bind the control to the results provided from the SiteMapDataSource control, simply use the ID of the SiteMapDataSource control on the page (the default value is SiteMapDataSource1) as the value of the DataSourceID attribute.

Restricting Access to Parts of the Application

Invariably you are going to build Web applications that have restricted access points. This starter kit is no different than many of these applications. The entire contents of the Library folder is only meant to be viewed and utilized by registered users. Also, the contents of the Admin folder are only meant for registered users who are contained in the role of Admin.

To accomplish these tasks, ASP.NET 2.0 includes membership and role management systems. These systems manage the authentication/authorization process of your application, as well as allow you to place specific users into custom defined roles.

Let's next take a look at how a system is put into place to manage these items.

Nesting Web.config Files

One of the first steps in establishing this type of system is to put in the proper Web.config files in your application. You might be well aware that placing a Web.config file in the root of your application will control many different aspects of how that application behaves.

This is relatively true, but in reality, the Web.config file is an overriding file—it is actually in place to override established settings and behaviors that have already been set in the server's machine.config file. The machine.config file controls the settings and behavior of every single application that resides on the server. To override settings that are placed in this file, you can simply place a Web.config file in the root of your application. This gives you the opportunity to put more application-specific settings in place.

However, in the Media Share Library Starter Kit, there is a need to apply settings that are only specific to a particular directory of the application. In fact, this occurs twice—once for the Library and another time for the Admin directory. Let's look at the rules that are distinct to some of the various directories of this starter kit and then we will look at how to apply these settings:

  • The root directory contains a single Web.config file, which provides open access to any anonymous user visiting the site. The rules established here will cascade to the rest of the application's sub-directories unless they are specifically overridden by a Web.config file residing in the directory.
  • The Library directory of the starter kit contains a Web.config file, which applies specific settings to every file and directory it contains. The contents of the Library directory are meant for only authenticated users irregardless of the role they might be in. The only concern is whether they are authenticated or not.
  • The Admin directory of the starter kit contains a Web.config file, which also applies specific settings to every file and directory it contains. The contents of the Admin directory are meant for only authenticated users who are contained in the Admin role. The Admin role is a custom defined role.

So, the point to remember here is that while your application can contain a single Web.config file in the root directory, you can override the settings applied application-wide by placing additional Web.config files in the sub-directories you are interested in manipulating. This is illustrated in Figure 5.

Aa479395.media3_fig05(en-us,MSDN.10).gif

Figure 5. Applying fine-grained control over specific directories in your application

Applying the Settings Required for the Root Directory

To get the membership and role management system up and running for the Media Share Library Starter Kit, let's first look at the settings that are applied to the Web.config file contained in the root directory of the application.

While there is a default membership provider that controls how the membership system works in your application, this provider can easily be overridden from the root Web.config file, as well. The default membership provider, the SqlMembershipProvider, controls how users are created and how they can log in to your application. Though the default membership provider is adequate in many ways, for this application, I decided to override the need for the user to have a strong password to make the login process a little simpler. Though less secure, I wanted to provide the end user the ability to use a password that they might more easily remember. Listing 7 shows how to requalify the SqlMembershipProvider in ASP.NET.

Listing 7. Reestablishing the SqlMembershipProvider

<membership>
   <providers>
      <clear/>
      <add name="AspNetSqlMembershipProvider" 
       type="System.Web.Security.SqlMembershipProvider, System.Web, 
          Version=2.0.0.0, Culture=neutral, 
          PublicKeyToken=b03f5f7f11d50a3a" 
       connectionStringName="LocalSqlServer" 
       requiresQuestionAndAnswer="false" requiresUniqueEmail="true" 
       passwordFormat="Hashed" minRequiredNonalphanumericCharacters="0" 
       minRequiredPasswordLength="3" />
   </providers>
</membership>

This bit of code from the Web.config file does a couple of things. The first step in the process is to clear out the previous providers that are declared in any parent Web.config files or any that might be contained in the machine.config file. This is done using the <clear/> element.

Now that the previously declared providers are cleared from the process, the next step is to establish the SqlMembershipProvider in the manner we are interested in. This is done through the use of the <add> element. In this case, there aren't too many attributes that are actually used to define the SqlMembershipProvider beyond the default specification of the provider.

From these attributes, the name attribute defines the name of the provider. You can give this any value you deem necessary for your application. The type attribute points to the instance of the SqlMembershipProvider—the provider we are interested in utilizing.

The connectionStringName attribute uses the LocalSqlServer connection to the database. This name is a reference to the declared connection in the <connectionStrings> section of the machine.config file shown in Listing 8.

Listing 8. The LocalSqlServer connection declared in the machine.config file

  <connectionStrings>
    <add name="LocalSqlServer" 
     connectionString="data source=.\SQLEXPRESS;
        Integrated Security=SSPI;
        AttachDBFilename=|DataDirectory|aspnetdb.mdf;
        User Instance=true" 
     providerName="System.Data.SqlClient" />
  </connectionStrings>

In the <connectionStrings> section of the Web.config, you will need to have a connection to the SQL Server Express aspnetdb.mdf file that, as you saw, is referenced from the SqlMembershipProvider.

Looking back at the SqlMembershipProvider declaration, the next attribute that is utilized is the requiresQuestionAndAnswer attribute. This is set to false and will remove the question/answer part of the registration process for new users. By default, this property is set to true—meaning that a question/answer is collected from the user registering for the application. If collected, this can then be used by various controls to allow end users to retrieve their password if forgotten. Since the Media Share Library doesn't include capabilities to retrieve passwords, the question/answer process can be removed.

Next, the requiresUniqueEmail is set to true, meaning that each user will have to enter in an e-mail address in the registration process that is not already stored within the membership database. If the e-mail address provided by the end user already exists, then the registration process will throw a validation error.

The next attributes—passwordFormat, minRequiredNonalphanumericCharacters, and minRequiredPasswordLength—control how passwords are administered in the application. In this case, the passwordFormat is set to Hashed. This will allow ASP.NET to hash the provided passwords before storing the password in the database. Then, when users log into the application, their provided password is hashed and compared to the hashed string that is stored in the database for a match. The minRequiredNonalphanumericCharacters is set to 0, removing the requirement to provide passwords that require characters such as 1, 2, 3, $, #, or !. Then finally, the minRequiredPasswordLength is set to 3, allowing users to enter in three character length passwords if they desire.

Remember, these modifications to the SqlMembershipProvider have lowered the security of the application. You have to weigh the ease of users logging into your application versus your application's required security and work with what you are comfortable with.

Beyond the settings applied to the SqlMembershipProvider in the root directory's Web.config file, other settings applied to this particular Web.config file that deal with the membership and role management systems include what is shown in Listing 9.

Listing 9. Part of the root directory's Web.config file

<configuration 
 xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.web>
      <roleManager enabled="true" />
      <anonymousIdentification enabled="True" />
      <authentication mode="Forms" />
   </system.web>
</configuration>

From the settings applied here, first the role management system is enabled since it is disabled by default. This will allow us to establish the Admin role from the Global.asax file on the application startup. Then the anonymous identification capability of the application is enabled so that we can deny or allow anonymous users, and finally, the authentication mode of the application is set to a forms-based authentication mode.

With these settings in place, this will mean that any anonymous user will be able to hit each and every file in the application (except the files that are disallowed for everyone).

Let's next look at how to disallow users from particular folders within the application.

Applying Settings to Other Web.config Files

Now that we have settings established in the root directory's Web.config file, the next step is to place additional Web.config files in the application to deny access to specific types of users in both the Library and Admin folders of the application.

Let's start by looking at the Web.config file that is contained in the Library folder. This is displayed in Listing 10.

Listing 10. The Web.config file from the Library folder

<?xml version="1.0" encoding="utf-8"?>
<configuration 
 xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.web>
        <authorization>
            <deny users="?" />
        </authorization>
    </system.web>
</configuration>

As stated before, you can nest Web.config files. Placing a Web.config file in the Library folder will allow you to define further rules or override other rules for each file or folder the Library folder contains. In this case, we are only interested in denying anonymous access to every page in the Library folder. This is done through the use of the <deny> element nested inside of the <authorization> section. Within the <deny> element, there is a specification to deny all anonymous users by using the users attribute. The question mark value means all anonymous users. So in the end, <deny users="?" /> means to deny all anonymous users to the contents of the Library folder. Therefore, to view the contents of the folder, the users will have to authenticate themselves through the login form provided in the application.

The next Web.config we are going to establish is placed inside the Admin folder. This Web.config file is shown here in Listing 11.

Listing 11. The Web.config file from the Admin folder

<?xml version="1.0"?>
<configuration 
 xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
      <system.web>
        <authorization>
          <allow roles="Admin" />
          <deny users="*" />
        </authorization>
      </system.web>
</configuration>

Since we are only going to want registered users who are contained in the Admin role to have access to the contents of the Admin folder, this Web.config file will need to use both the <allow> and <deny> elements of the <authorization> section of the document.

First, looking at the <deny> element, you will notice that the value of the users attribute is different than what was applied to the Web.config file that is contained in the Library folder. In this case, instead of denying all anonymous users by using a question mark, we need to use the asterisk. An asterisk specifies all users, whether they are registered or not.

Now that all users are disallowed from browsing the contents of the Admin folder, the next step is to allow someone to access the single file contained in the folder. This is done through the use of the <allow> element. In this case, instead the users attribute, we will use the roles attribute and specify that we are only interested in allowing users contained in the Admin role to access the page in this folder.

Providing Login and Registration Forms for Users

Now that the application is configured for membership and role management as we wish, the next step is to provide the means for end users to log into the application. This can be accomplished in many different ways, but the Media Share Library Starter Kit makes use of the Login server control placed on the Login.aspx page shown in Listing 12.

Listing 12. Using the Login server control

<fieldset>
   <legend>Login</legend>
   <br />
   You must first register before you can login.<br /><br />
   <asp:Login ID="Login1" runat="server" CreateUserUrl="~/Join.aspx" 
    UserNameLabelText="Username:">
   </asp:Login>
</fieldset>

There isn't much to this Login server control. The only extensions to it are through the use of the CreateUserUrl attribute and the UserNameLabelText attribute. The CreateUserUrl attribute points to the location of the application's registration page (in this case, Join.aspx) while the UserNameLabelText attribute simply changes the name of the UserName label. Generating this page in the browser produces the following results, illustrated in Figure 6.

Aa479395.media3_fig06(en-us,MSDN.10).gif

Figure 6. The generated Login server control

The Join.aspx page allows anonymous users to register for the site, thereby allowing them to become registered users. Figure 7 shows the two-phase registration process.

Aa479395.media3_fig07(en-us,MSDN.10).gif

Figure 7. Users registering for the starter kit application

The first step in the registration process is customized. The second step of the process is the standard process, though the security question/answer section has been removed by ASP.NET automatically since we specified in the Web.config file to turn off the question/answer functionality of the membership system. The code for this control is shown in Listing 13.

Listing 13. Registering users with the CreateUserWizard server control

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" 
 LoginCreatedUser="True">
   <WizardSteps>
      <asp:WizardStep ID="WizardStep1" Runat="server" 
       Title="Personal Information" StepType="Start">
         <table width="100%">
            <tr><td colspan="2">First Step: Enter your personal 
             information</td></tr>
            <tr><td>
             Firstname: </td><td>
            <asp:TextBox ID="Firstname" Runat="server"></asp:TextBox>
            </td></tr><tr><td>
             Lastname: </td><td>
            <asp:TextBox ID="Lastname" Runat="server"></asp:TextBox>
            </td></tr><tr><td>
             Group: </td><td>
            <asp:TextBox ID="Group" Runat="server"></asp:TextBox>
            </td></tr>
         </table>
      </asp:WizardStep>
      <asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server">
      </asp:CreateUserWizardStep>
      <asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server">
      </asp:CompleteWizardStep>
   </WizardSteps>
</asp:CreateUserWizard>

Looking over this code, you can see that there are three wizard steps defined in the CreateUserWizard control. The first step, defined through the use of the WizardStep server control, is a custom step in the process. This step was added to collect some personal information from the user. These collected information bits will then be added to the built-in personalization system (discussed shortly).

The second wizard step, CreateUserWizardStep1, is the default wizard step that asks for users' login/password combination as well as their e-mail address. The last step in the process is for when users have completed the registration process.

Probably one of the more important attributes to pay attention to in the CreateUserWizard control is the LoginCreatedUser attribute. When set to True, the CreateUserWizard control will log the newly created user into the application automatically. By default, this property is set to False.

When the end user clicks on the Create User button, the following event (shown in Listing 14) is launched in the code-behind page for the Join.aspx page.

Listing 14. The button event for creating a user

Protected Sub CreateUserWizard1_ContinueButtonClick(ByVal sender As 
   Object, ByVal e As System.EventArgs) Handles 
   CreateUserWizard1.ContinueButtonClick
        
   ' Assign Profile items entered through registration process.
   Profile.FirstName = Firstname.Text
   Profile.LastName = Lastname.Text
   Profile.Group = Group.Text
   Profile.MemberSince = DateTime.Now()
   Profile.Email = CreateUserWizard1.Email
   Response.Redirect("~/Default.aspx")
End Sub

This event places the personal pieces of information in the personalization system and then redirects the user to the Default.aspx page in the root directory as a registered user.

Working with a Personalization System

As you can see from the previous code listing, we are storing some of the end user's personal information. This information is stored into the built-in personalization system provided with ASP.NET 2.0.

To activate the system, you have to make some setting declarations in the root directory's Web.config file. This is illustrated in Listing 15.

Listing 15. Declaring personalization properties for the application

<profile>
   <properties>
      <add name="FirstName" />
      <add name="LastName" />
      <add name="Email" />
      <add name="Group" />
      <add name="MemberSince" type="System.DateTime" />
   </properties>
</profile>

Declaring personalization properties is done in the <profile> section of the Web.config file. Within the <profile> section, create a <properties> section that will allow you to add a series of <add> elements. These <add> elements are used to declare specific profile properties. In this case, there are five properties declared—FirstName, LastName, Email, Group, and MemberSince. The MemberSince property is even further defined through the addition of the type attribute specifying that this property's type is System.DateTime. The other profile properties don't have this further specification applied to them, meaning that the default type of System.String is applied instead.

With this small section of code in place in the Web.config, you will then be able to assign values to these properties as shown here:

Profile.FirstName = TextBox1.Text

You can also use the values contained in the property in your assignments:

TextBox1.Text = Profile.Email

In the next ASP.NET Jumpstart article, you will be able to see how these profile properties are used in the presentation of some of the ASP.NET pages.

Applying Styles

ASP.NET 2.0 also provides you the means of applying styles to your pages from a centralized location. ASP.NET Themes (mentioned earlier in this article) allow you to place all your styles for server controls and other page elements in a single location in the application.

To build a centralized style data store, create a folder in your application called App_Themes. To create a theme, or a collection of styles to use from page to page in the application, create an additional folder inside the App_Themes folder. The name of the folder will be the name of your theme. You can have as many themes in the App_Themes folder as you want. In the case of the basic install of the Media Share Library Starter Kit, there is only a single theme, titled Evjen.

A theme can contain a collection of skin or CSS files. The Evjen theme contains both of these elements. The CSS file is standard and should be treated no differently than you would normally treat your CSS files. The skin file, though, is something that will be new to most people. This is an XML file that allows you to declare standard look-and-feels for server controls contained in the application. Looking at the Evjen.skin file, you will see a small list of server control declarations. Listing 16 shows one of these control declarations.

Listing 16. The Menu server control as declared in the Evjen.skin file

<asp:Menu runat="server" Font-Bold="True" StaticDisplayLevels="5" 
 BackColor="#F7F6F3" DynamicHorizontalOffset="2" Font-Names="Verdana" 
 Font-Size="0.8em" ForeColor="#7C6F57" StaticSubMenuIndent="10px" 
 Width="100%" BorderColor="Brown" BorderWidth="1">
    <StaticSelectedStyle BackColor="#F7F6F3" />
    <StaticMenuItemStyle HorizontalPadding="5px" VerticalPadding="2px" />
    <DynamicHoverStyle BackColor="#7C6F57" Font-Bold="False" 
     ForeColor="White" />
    <DynamicMenuStyle BackColor="#F7F6F3" />
    <DynamicSelectedStyle BackColor="#F7F6F3" />
    <DynamicMenuItemStyle HorizontalPadding="5px" VerticalPadding="2px" />
    <StaticHoverStyle BackColor="#7C6F57" Font-Bold="True" 
     ForeColor="White" />
</asp:Menu>

Looking over this control declaration, you can see that there aren't any behavior declarations. Instead, there are only style declarations. The other important item to notice about this control declaration is that there isn't an ID attribute used. The reason is due to the fact that this bit of server control will be applied to each and every instance of the Menu server control that is used on a page on which the Evjen theme is applied.

How do you apply the Evjen theme (or your own custom theme) to a page? This is done through the Theme attribute in the @Page directive as shown in Listing 17.

Listing 17. The @Page directive of the content page

<%@ Page Language="VB" MasterPageFile="~/MediaLibraryMain.master" 
    AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" 
    Title="Media Share Library" Theme="Evjen" %>

This is a nice way to keep all your style settings in a centralized location. Then, when a change has to be made to the overall look-and-feel of the application, you can make these changes in a single location and have that change reflected throughout the application. It couldn't be any simpler.

Conclusion

This article gave you a look at building the foundations of the Media Share Library Starter Kit. First, this article looked at how to apply master pages to your application. Then we took a look at the membership and role management system, as well as how to apply personalization, navigation, and more.

The next article in this ASP.NET Jumpstart series will show you how to use some of the new and exciting controls found in ASP.NET 2.0.

Have fun and happy coding!

 

About the author

Bill Evjen is an active proponent of .NET technologies and community-based learning initiatives for .NET. He has been actively involved with .NET since the first bits were released in 2000. In the same year, Bill founded the St. Louis .NET User Group (http://www.stlnet.org), one of the world's first .NET user groups. Bill is also the founder of the International .NET Association (http://www.ineta.org), which represents more than 400,000 members worldwide.

Based in St. Louis, Missouri, USA, Bill is an acclaimed author and speaker on ASP.NET and XML Web services. He has written or coauthored more than 10 books including Professional ASP.NET 2.0, Professional C#, 4th Edition and Professional VB 2005, 4th Edition (Wrox), XML Web Services for ASP.NET, Web Services Enhancements: Understanding the WSE for Enterprise Applications, Visual Basic .NET Bible, and ASP.NET Professional Secrets (all published by Wiley). In addition to writing, Bill is a speaker at numerous conferences including DevConnections, VSLive, and TechEd.

Bill is a Technical Architect for Reuters, the international news and financial services company, and he travels the world speaking to major financial institutions about the future of the IT industry. He graduated from Western Washington University in Bellingham, Washington, with a Russian language degree. When he isn't tinkering on the computer, he can usually be found at his summer house in Toivakka, Finland. You can reach Bill at evjen@yahoo.com. He presently keeps his weblog at http://www.geekswithblogs.net/evjen.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.