Professional ASP.NET 3.5 in C# and Visual Basic Part 77 pps
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (208.66 KB, 10 trang )
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 717
Chapter 14: Site Navigation
Listing 14-34: Locking down the AdminOnly.aspx page in the web.config
<configuration>
<location path="AdminOnly.aspx">
<system.web>
<authorization>
<allow roles="Admin" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>
Now, because the
AdminOnly.aspx
page is accessible only to the users who are in the Admin role, the
next step is to allow users to login to the application. The application demo accomplishes this task by
creating a
Default.aspx
page that contains a Login server control as well as a TreeView control bound
to a SiteMapDataSource control. This simple ASP.NET page is presented in Listing 14-35.
Listing 14-35: The Default.aspx page
<%@ Page Language="VB" %>
<html xmlns=" /><head runat="server">
<title>Main Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Login ID="Login1" runat="server">
</asp:Login>
<br />
<asp:TreeView ID="TreeView1" runat="server"
DataSourceID="SiteMapDataSource1" ShowLines="True">
</asp:TreeView>
<br />
<asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" />
</div>
</form>
</body>
</html>
With the
Default.aspx
page in place, another change is made to the
Web.sitemap
file that was originally
presented in Listing 14-1. For this example, you add a
<
siteMapNode
> element that works with the new
AdminOnly.aspx
page. This node is presented here:
<siteMapNode title="Administration" description="The Administrators page"
url="AdminOnly.aspx" roles="Admin" />
After all items are in place in your application, the next step is to enable security trimming for the site
navigation system.
717
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 718
Chapter 14: Site Navigation
Enabling Security Trimming
By default, security trimming is disabled. Even if you start applying values to the
roles
attribute for any
<
siteMapNode
> element in your
web.config
file, it does not work. To enable security trimming, you
must fine-tune the provider declaration for the site navigation system.
To make the necessary changes to the XmlSiteMapProvider, you need to make these changes high up
in the configuration chain, such as to the
machine.config
file or the default
web.config
file, or you can
make the change lower down, such as in your application’s
web.config
file. This example makes the
change in the
web.config
file.
Figure 14-36
To alter the XmlSiteMapProvider in the
web.config
file, you first clear out the already declared instance.
After it is cleared, you then redeclare a new instance of the XmlSiteMapProvider, but this t ime you enable
security trimming, as illustrated in Listing 14-36.
718
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 719
Chapter 14: Site Navigation
Listing 14-36: Enabling security trimming in the provider
<configuration>
<system.web>
<siteMap>
<providers>
<clear />
<add siteMapFile="web.sitemap" name="AspNetXmlSiteMapProvider"
type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
securityTrimmingEnabled="true" />
</providers>
</siteMap>
</system.web>
</configuration>
Figure 14-37
719
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 720
Chapter 14: Site Navigation
From this example, you can see that a new XmlSiteMapProvider is defined and the
securityTimmingEn-
abled
attribute is then set to
true
(shown in bold). With security trimming enabled, the roles attribute in
the
<
siteMapNode
> element is utilized in the site navigation system.
To test it out for yourself, run the
Default.aspx
page. You are first presented with a page that does not
include the link to the administration portion of the page, as illustrated in Figure 14-36.
From this figure, you can see that the Administration link is not present in the TreeView control. Now,
however, log in to the application as a user contained in the Admin role. You then see that, indeed, the
site navigation has changed to reflect the role of the user, as presented in Figure 14-37.
Security trimming is an ideal way of automatically altering the site navigation that is presented to users
based upon the roles they have in the role management system.
Nesting SiteMap Files
You are not required to place all your site navigation within a single
Web.sitemap
file. In fact, you can
spread it out into multiple
.sitemap
files if you wish and then bring them all together into a single
.sitemap
file — also known as nesting
.sitemap
files.
For instance, suppose you are using the sitemap file from Listing 14-1 and you have a pretty large amount
of site navigation to add under the area of Entertainment. You could put all this new information in the
current
Web.sitemap
file, or you could keep all the Entertainment links in another sitemap file and just
reference that in the main sitemap file.
In the simplest case, nesting sitemap files is easily achievable. To see it in action, create a new
.sitemap
file (called
Entertainment.sitemap
) and place this file in your application. An example
Entertain-
ment.sitemap
file is presented in Listing 14-37.
Listing 14-37: The Entertainment.sitemap
<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns=" >
<siteMapNode url="Entertainment.aspx" title="Entertainment"
description="The Entertainment Page">
<siteMapNode url="Movies.aspx" title="Movies"
description="The Latest in Movies" />
<siteMapNode url="Fashion.aspx" title="Fashion"
description="The Latest in Fashion" />
</siteMapNode>
</siteMap>
You can place the
Entertainment.sitemap
in the root directory where you also have the main
Web.sitemap
file. Now, working from the sitemap file that from the earlier Listing 14-1, you make the
following addition to the bottom of the list as presented in Listing 14-38.
Listing 14-38: Additions to the Web.sitemap file
<siteMapNode siteMapFile="Entertainment.sitemap" />
720
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 721
Chapter 14: Site Navigation
Instead of using the standard
url
,
title
,and
description
attributes, you just point to the other sitemap
file to be included in this main sitemap file using the
siteMapFile
attribute. Running this page gives you
results similar to those presented in Figure 14-38.
Figure 14-38
Another approach to nesting sitemap files is to build a second provider in the sitemap provider model
definitions and to then use the
provider
attribute within the <
siteMapNode
> element to reference this
declaration. To accomplish this task, you first add a new sitemap provider reference in the
web.config
file. This is illustrated in Listing 14-39.
Listing 14-39: Using another provider in the same Web.sitemap file
<configuration>
<system.web>
<siteMap>
<providers>
<add siteMapFile="Entertainment.sitemap" name="AspNetXmlSiteMapProvider2"
type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</siteMap>
</system.web>
</configuration>
From this bit of code, you can see that a second provider is defined. Defining a second sitemap provider
does not mean that you have to use the
<
clear /
> element in the <
provider
> section, but instead, you
simply define a new provider that has a new name. In this case, the name of the provider is
AspNetXml-
SiteMapProvider2
. Also, within this provider definition, the
siteMapFile
attribute is used to point to
the name of the sitemap file that should be utilized.
With this in place, you can then reference this declaration by using the
provider
attribute within the
<
siteMapNode
> element of the
Web.sitemap
file. To add the
Entertainment.sitemap
file in this manner,
your
<
siteMapNode
> element should take the form presented in Listing 14-40.
721
Evjen c14.tex V2 - 01/28/2008 2:39pm Page 722
Chapter 14: Site Navigation
Listing 14-40: Using a second provider in the Web.sitemap file
<siteMapNode provider="AspNetXmlSiteMapProvider2" />
This gives you the same results as those shown in Figure 14-38. Besides providing another way of nesting
sitemap files, you gain a lot of power using the
provider
attribute. If you build a new sitemap provider
that pulls sitemap navigation information from another source (rather than from an XML file), you can
mix those results in the main
Web.sitemap
file. The end result could have items that come from two or
more completely different data sources.
Summary
This chapter introduced the navigation mechanics that ASP.NET 3.5 provides. At the core of the naviga-
tion capabilities is the power to detail the navigation structure in an XML file, which can then be utilized
by various navigation controls — such as the new TreeView and SiteMapPath controls.
The powerful functionality that the navigation capabilities provide saves you a tremendous amount of
coding time.
In addition to showing you the core infrastructure for navigation in ASP.NET 3.5, this chapter also
described both the TreeView and SiteMapPath controls and how to use them throughout your a ppli-
cations. The great thing about these controls is that, right out of the box, they can richly display your
navigation hierarchy and enable the end user to work through the site easily. In addition, t hese con-
trols are easily changeable so that you can go beyond the standard appearance and functionality that
they provide.
Along with the TreeView server control, this chapter also looked at the Menu server control. You
will find a lot of similarities between these two controls as they both provide a means to look at
hierarchical data.
Finally, this chapter looked at how to achieve URL mapping, as well as how to localize your
Web
.sitemap
files and filter the results of the site navigation contents based upon a user’s role in the role
management system.
722
Evjen c15.tex V2 - 01/28/2008 2:44pm Page 723
Personalization
Many Web applications must be customized with information that is specific to the end user who
is presently viewing the page. In the past, the developer usually provided storage of personal-
ization properties for end users viewing the page by means of cookies, the
Session
object, or
the
Application
object. Cookies enabled storage of persistent items so that when the end user
returned to a Web page, any settings related to him were retrieved in order to be utilized again by
the application. Cookies are not the best way to a pproach persistent user data storage, however,
mainly because they are not accepted by all computers and also because a crafty end user can easily
alter them.
As you will see in Chapter 16, ASP.NET membership and role management capabilities are ways
that ASP.NET can conveniently store information about the user. How can you, as the developer,
use the same mechanics to store custom information?
ASP.NET 3.5 provides you with an outstanding feature — personalization. The ASP.NET personal-
ization engine provided with this latest release can make an automatic association between the end
user viewing the page and any data points stored for that user. The personalization properties that
are maintained on a per-user basis are stored on the server and not on the client. These items are
conveniently placed in a data store of your choice (such as Microsoft’s SQL Server) and, therefore,
the end user can then access these personalization properties on later site visits.
This feature is an ideal way to start creating highly customizable and user-specific sites without
building any of the plumbing beforehand. In this case, the plumbing has been built for you! The
personalization feature is yet another way that the ASP.NET team is making developers more pro-
ductive and their jobs easier.
The Personalization Model
The p ersonalization model provided with ASP.NET 3.5 is simple and, as with most items that come
with ASP.NET, it is an extensible model as well. Figure 15-1 shows a simple diagram that outlines
the personalization model.
Evjen c15.tex V2 - 01/28/2008 2:44pm Page 724
Chapter 15: Personalization
Server Controls
Web Parts
Interfaces
Control PersonalizationProfile API
Data Stores
Custom Data Store
SQL Server
7.0/2000/2005/2008
Figure 15-1
From this diagram, you can see the three layers in this model. First, look at the middle layer of the per-
sonalization model — the Personalization Services layer. This layer contains the Profile API. This new
Profile API layer enables you to program your end user’s data points into one of the lower-layer data
stores. Also included in this layer are the server control personalization capabilities, which are important
for the Portal Framework and the use of Web Parts. The Portal Framework and Web Parts are discussed
in Chapter 17.
Although certain controls built into ASP.NET can utilize the personalization capabilities for storing
information about the page settings, you can also use this new engine to store your own data points. As
with Web Parts, these points can be used within your ASP.NET pages.
Below the Personalization Services layer, you find the default personalization data provider for working
with Microsoft’s SQL Server 2008, 2005, or 2000, as well as the new Microsoft SQL Server Express Edition
files. You are not limited to just this one data store when applying the personalization features of ASP.NET
3.5; you can also extend the model and create a custom data provider for the personalization engine.
You can read about how t o create your own providers in Chapter 13.
Now that you have looked briefly at the personalization model, you can begin using it by creating some
stored personalization properties that can be used later within your applications.
724
Evjen c15.tex V2 - 01/28/2008 2:44pm Page 725
Chapter 15: Personalization
Creating Personalization Proper ties
The nice thing about creating custom personalization properties is that you can do it so easily. After
these properties are created, you gain the capability to have strongly typed access to them. It is also
possible to create personalization properties that are used only by authenticated users, and also some
that anonymous users can utilize. These data points are powerful — mainly because you can start using
them immediately in your application without building any underlying infrastructures to support them.
The first step is to create some simple personalization properties. Later, you learn how to use these
personalization properties within your application.
Adding a Simple Personalization Property
The first step is to decide what data items from the user you are going to store. For this example, create
a few items about the user that you can use within your application; assume that you want to store the
following information about the user:
❑ First name
❑ Last name
❑ Last visited
❑ Age
❑ Membership Status
ASP.NET has a heavy dependency on storing configurations inside XML files, and the ASP.NET 3.5
personalization engine is no different. All these customization points concerning the end user are defined
and stored within the
web.config
file of the application. This is illustrated in Listing 15-1.
Listing 15-1: Creating personalization properties in the web.config file
<configuration>
<system.web>
<profile>
<properties>
<add name="FirstName" />
<add name="LastName" />
<add name="LastVisited" />
<add name="Age" />
<add name="Member" />
</properties>
</profile>
<authentication mode="Windows" />
</system.web>
</configuration>
725
Evjen c15.tex V2 - 01/28/2008 2:44pm Page 726
Chapter 15: Personalization
Within the
web.config
file and nested within the <
system.web
> section of the file, you create
a
<
profile
> section in order to work with the ASP.NET 3.5 personalization engine. Within this
<
profile
> section of the
web.config
file, you create a <
properties
> section. In this section, you can
define all the properties you want the personalization engine to store.
From this code example, you can see that it is rather easy to define simple properties using the
<
add
>
element. This element simply takes the
name
attribute, which takes the name of the property you want
to persist.
You start out with the assumption that accessing the page you will build with these properties is already
authenticated using Windows authentication (you can read more on authentication and authorization in
the next chapter). Later in this chapter, you look at how to apply personalization properties to anonymous
users as w ell. The capability to apply personalization properties to anonymous users is disabled by
default (for good reasons).
After you have defined these personalization properties, it is just as easy to use them as it is to define
them. The next section looks at how to use these definitions in an application.
Using Personalization Properties
Now that you have defined the personalization properties in the
web.config
file, it is possible to use these
items in code. For example, you can create a simple form that asks for some of this information from the
end user. On the
Button_Click
event, the data is stored in the personalization engine. Listing 15-2 shows
an example of this.
Listing 15-2: Using the defined personalization properties
VB
<%@ Page Language="VB" %>
<script runat="server">
Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
If Page.User.Identity.IsAuthenticated Then
Profile.FirstName = TextBox1.Text
Profile.LastName = TextBox2.Text
Profile.Age = TextBox3.Text
Profile.Member = Radiobuttonlist1.SelectedItem.Text
Profile.LastVisited = DateTime.Now().ToString()
Label1.Text = "Stored information includes:<p>" & _
"First name: " & Profile.FirstName & _
"<br>Last name: " & Profile.LastName & _
"<br>Age: " & Profile.Age & _
"<br>Member: " & Profile.Member & _
"<br>Last visited: " & Profile.LastVisited
Else
Label1.Text = "You must be authenticated!"
End If
End Sub
</script>
726
