New Features and Tools in ASP.NET 2.0

This chapter is from the book 

New Features

This chapter isn't an in-depth look at any specific feature—instead we are going to give you a taste of what's to come so you can see how much easier Web development is going to be. For this outlook we've broken down the new features into rough end-to-end scenarios.

Templates for a Consistent Look and Feel

ASP.NET 1.x provides an easy way to develop Web sites, but one thing that has become apparent is the lack of an architecture for applying a consistent look and feel. Several workaround techniques emerged:

• Creating a custom class object that inherits from Page and having this custom page preload controls

• Creating a templated server control, where the templates provide the layout areas for each page, and using this control on every page

• Having User Controls for common areas of the site, such as headings, menus, and footers

Of these, the first two require knowledge of creating server controls, and although this is a topic most ASP.NET developers could master, it may not be one they've had experience with. Therefore a solution using custom server controls tends to be avoided. The last option, though, is a simple solution, easy to create and implement. User Controls were created to provide reusable functionality, and this is a great use for them. However, to apply a consistent look and feel you need to first place the User Controls on each page, then ensure that they are placed in the same place on each page. In other words, you really need a page template, and in reality this manifests itself as an ASP.NET file that you simply copy for each new page. The danger of this approach is that it's too easy to modify a page and change the layout for that single page.

To provide a templating solution, ASP.NET 2.0 has the concept of master pages, which provide a template for the look and implementation of a page. A master page is an ASP.NET page that provides a template for other pages, giving shared page-level layout and functionality. The master page defines placeholders for the content, which can be overridden by child pages. The resultant page is a combination of the master page and the child page, as shown in Figure 1.1.

Figure 1.1 Combining a master page and a child page

Styles for Controls

The second major feature of ASP.NET 2.0 that deals with the look and feel of a site is that of themes. Theming, or skinning, has become very popular, allowing users to create a customized look for applications. On the Windows desktop two of the most popular themed applications are audio players (Winamp and Windows Media Player), and with some additional software, even Windows XP can be themed.

The popularity of theming is due to the nature of humans—we like to choose the way things look, and we like to express our individuality. This is easy on the desktop, where users generally have a single machine each. With Web sites, however, theming becomes a more difficult issue because of the number of users. Tracking which users have which themes and managing those themes becomes an overhead that site administrators don't want to get involved with.

Some Web sites provide forms of theming, but these are relatively limited in terms of customization, perhaps allowing only a choice of color scheme. Other sites provide a selection of stylesheets for users to pick from, assuming their browsers support this feature, or alternatively change the stylesheet on the server. This allows not only color schemes to be selected but also complete style choices, such as fonts, style of borders, and so on.

In ASP.NET 2.0 the goals for theming are quite simple.

• Make it simple to customize the appearance of a site or page, using the same design tools and methods used when developing the page itself. This means there's no need to learn any special tools or techniques to add themes to a site.

• Allow themes to be applied to controls, pages, and even entire sites. For example, this allows users to customize parts of a site while ensuring that other parts (such as corporate identity) aren't customized.

• Allow all visual properties to be customized, thus ensuring that when themed, pages and controls can achieve a consistent style.

The implementation of this in ASP.NET 2.0 is built around two areas: skins and themes. A skin is a set of properties and templates that can be applied to controls. A theme is a set of skins and any other associated files (such as images or stylesheets). Skins are control specific, so for a given theme there could be a separate skin for each control within that theme. Any controls without a skin inherit the default look. There are two types of themes.

• Customization themes override control definitions, thus changing the look and feel of controls. Customization themes are applied with the Theme attribute on the Page directive.

• Stylesheet themes don't override control definitions, thus allowing the control to use the theme properties or override them. Stylesheet themes are applied with the StylesheetTheme attribute on the Page directive.

The implementation is simple because a skin uses the same definition as the server control it is skinning, and themes are just a set of files in a directory under the application root. For example, consider the sample directory structure shown below:

default.aspx
\Themes
  \MyTheme
    MySkin.skin
  \YourTheme
    YourSkin.skin

Each theme consists of a directory under the Themes directory. Within each theme there is a file with a .skin suffix, which contains the skin details for that theme. For example, MySkin.skin might contain:

<asp:Label SkinID="Normal" runat="server"
  Font-Bold="True" BackColor="#FFC080" />
<asp:Label SkinID="Comic" runat="server"
  Font-Italic="True" Font-Names="Comic Sans MS" />

This defines two skins for the Label control, each with different visual properties. The theme can be chosen by setting the appropriate page-level property, and the skin is chosen by setting a control-level property, as demonstrated in the following code snippets.

<%@ Page Theme="MyTheme" %>

<form runat="server">

  <asp:Label SkinID="Comic" Text="A Label" />

</form>

or

<%@ Page StylesheetTheme="MyTheme" %>

<form runat="server">

  <asp:Label SkinID="Comic" Text="A Label" />

</form>

Both of these can be set at runtime as well as design time, so this provides an extremely powerful solution, especially when connected with the new Personalization features.

Securing Your Site

With the large amount of business being done on the Web, security is vitally important for protecting not only confidential information such as credit card numbers but also users' personal details and preferences. Thus you have to build into your site features to authenticate users. This was easy to do in ASP.NET 1.x, although you still had to write code. Security was created by picking your preferred security mechanism (most often Forms Authentication) and then adding controls to your page to provide the login details—username, password, "remember me" checkbox, and so on. There was no built-in mechanism for storing personal details, so this was a roll-it-yourself affair.

With ASP.NET 2.0, the pain has been taken out of both areas. For login functionality, there is now

• A Login control, providing complete functionality for logging into a site

• A LoginStatus control, which indicates the login status and can be configured to provide automatic links to login and logout pages

• A LoginName control to display the current (or anonymous) name

• A LoginView control, providing templated views depending on the login status

• A CreateUser wizard, to allow simple creation of user accounts

• A PasswordRecovery control, encompassing the "I forgot my password" functionality

For example, to add login features to your page all you need to do is add the following code:

<form runat="server">
  <asp:Login runat="server" />
</form>

This gives us the simple interface shown in Figure 1.2.

Figure 1.2 The Login control

This could be achieved easily in previous versions of ASP.NET, but not with such simplicity. You needed labels, text entry boxes, buttons, and validation, whereas now it's all rolled into one control. Sure it looks plain, but this is the basic unformatted version. Using the design tool Visual Studio .NET (more on that in Chapter 2), you can auto-format this for a better look. You can also skin the interface, as shown in Figure 1.3, or even template it to provide your own customized look. Along with the other login controls you get a complete solution for handling user logins.

Figure 1.3 A skinned Login control

The user interface isn't the only part of logging into a site; there's also the code needed to validate the user against a data store. With ASP.NET 1.x this required not only code to be written but also knowledge of what that data store was and how it stored data. ASP.NET 2.0 introduces a new Membership API, whose aim is to abstract the required membership functionality from the storage of the member information. For example, validation of user credentials can now be replaced with the code shown in Listing 1.1.

Example 1.1. Validating User Credentials

If Membership.ValidateUser(Email.Text, Password.Text) Then
  ' user is valid
Else
  ' user is not valid
End If

What's even better is that when using the Login control you don't even have to do this—the control handles it for you.

The great strength of the Membership API is that it is built on the idea of Membership Providers, with support for Microsoft SQL Server and Access supplied by default. To integrate custom membership stores you simply need to provide a component that inherits from the Membership base class and add the new provider details to the configuration file.

The Membership API has some simple goals.

• Offer an easy solution for authenticating and managing users, requiring no knowledge of the underlying storage mechanism.

• Provide support for multiple data providers, allowing data stored about users to come from different data stores.

• Provide comprehensive user management in a simple-to-use API, giving an easy way for developers to store and access user details.

• Give users a unique identity, allowing integration with other services such as the Personalization and Role Manager features.

Personalizing Your Site

One of the areas driving changes on the Internet is that of communities. People like to belong, and the Internet is a big, lonely place. Community sites give you a home, a sense of belonging. Part of that comes from being in contact with like-minded people, and part comes from the features some of these sites offer. Our houses are decorated to our style, and many of us customize our Windows desktop, so why shouldn't our favorite Web sites offer the same opportunity?

Hand in hand with the Membership API lie the Personalization features. These provide a simple programming model for storing user details (including those of anonymous users), with easy customization. Like Membership, Personalization can be configured to work with multiple data providers and provides an easy way to define custom properties for each user. This leads to a user profile with strong types, allowing easy access within ASP.NET pages. For example, you can create a profile with Name, Address, and Theme as properties and a page that allows the user to update them, as shown in Listing 1.2.

Example 1.2. Using the Profile Custom Properties

<script runat="server">

  Sub Page_Load(Sender As Object, E As EventArgs)

    Name.Text = Profile.Name
    Address.Text = Profile.Address
    UserTheme.Text = Profile.Theme

  End Sub

  Sub Update_Click(Sender As Object, E As EventArgs)

    Profile.Name = Name.Text
    Profile.Address = Address.Text
    Profile.Theme = UserTheme.Text

  End Sub

</script>

<form runat="server">
  Name:    <asp:TextBox id="Name" runat="server" /> <br />
  Address: <asp:TextBox id="Address" runat="server" /> <br />
  Theme:   <asp:TextBox id="UserTheme" runat="server" /> <br />
  <asp:Button Text="Update" onClick="Update_Click" runat="server" />
</form>

The simplicity of this method means we only have to deal with the user profile. We don't need to know how it stores the data—we just deal with the properties each profile has. This personalization also allows us to easily use the theming capabilities, changing the theme when the page is created, as demonstrated below.

Sub Page_PreInit(Sender As Object, E As EventArgs)

  Me.Theme = Profile.Theme

End Sub

To ensure that the theme customization is applied before the controls are created we use the new PreInit event.

Creating Portals

As if customization of a site's look weren't enough, ASP.NET 2.0 also brings a way to alter the structure with its new portal framework.

The success of the ASP.NET IBuySpy portal application and its offshoots shows that customized sites are popular. The issue has always been how to provide a consistent look while still allowing user customization, not only of the style but also of the content and placement of content. Microsoft has already implemented solutions to provide this functionality, including SharePoint Server and Outlook Web Parts.

In ASP.NET 2.0, Web Parts become the underlying technology for all Microsoft portal applications, providing a single easy-to-use, extensible framework. The concept revolves around two key sets of controls—a set of zone controls and a range of different Web Part controls. The zone identifies areas on the page in which the appearance or behavior of the content is consistent (e.g., the colors, styles, and layout orientation), and the Web Parts identify the individual content areas or modules within each zone. There are different types of Web Part controls for different purposes, for example:

• GenericWebPart, which is used to reference assemblies or user controls that contain the content that is normally visible on the page

• A range of catalog parts, which display parts that are not currently on the page but are available to be added

• A range of editor parts such as the AppearanceEditorPart and the LayoutEditorPart, which allow customization of the visible parts

For example, consider an intranet site that needs a selection of areas of content, such as events and company information. Figure 1.4 shows a sample page.

Figure 1.4 Sample intranet site using the portal framework

This page has two main areas of content—the top area containing the three Web Parts named Canteen Menu, My Stocks, and Meetings, and the lower area containing two Web Parts named Product List and Customer Details. Each of these main areas is a WebPartZone control, and the content within them is made up of individual user controls that are declared and referenced in the <ZoneTemplate> section of the relevant WebPartZone. The code for the top WebPartZone control appears in Listing 1.3.

Example 1.3. Sample Intranet Site Using Web Parts

<asp:WebPartZone id="EventsZone" runat="server"
     PartChromeType="TitleAndBorder"
     VerbButtonType="Image"
     MenuPopupImageUrl="images/clickdown.gif"
     MinimizeVerb-ImageUrl="images/minimize.gif"
     RestoreVerb-ImageUrl="images/restore.gif"
     CloseVerb-ImageUrl="images/close.gif"
     EditVerb-ImageUrl="images/edit.gif"
     HelpVerb-ImageUrl="images/help.gif"
     LayoutOrientation="Horizontal"
     EmptyZoneText="Events Zone"
     HeaderText="Today's Events"
     SelectedPartChromeStyle-BorderStyle="Solid"
     SelectedPartChromeStyle-BorderWidth="5"
     SelectedPartChromeStyle-BorderColor="#ff3300"
     MenuStyle-BorderWidth="1"
     MenuStyle-BorderColor="#000000"
     MenuStyle-BorderStyle="Solid">
  <PartTitleStyle BackColor="#2254B1" ForeColor="White"
             Font-Bold="True" />
  <PartStyle CellSpacing="0"  BackColor="#C0FFC0"
             BorderColor="#81AAF2" BorderStyle="Solid"
             BorderWidth="1px" />
  <ZoneTemplate>
    <ahh:Canteen id="pCanteen" runat="server"
          Title="Canteen Menu" />
    <ahh:Stocks id="pStocks" runat="server"
        Title="My Stocks" />
    <ahh:Meetings id="pMeetings" runat="server"
        Title="Meetings" />
  </ZoneTemplate>
</asp:WebPartZone>

At first glance this doesn't look like much improvement over existing layout methods such as user controls—in fact, it looks more complex. However, the framework on which Web Parts is built is great for developers and users alike. Developers only have to drop user controls or server controls into a ZoneTemplate to automatically receive Web Parts functionality.

For example, the Personalization features allow each Web Part to be moved to another location within its zone or to a different zone. Moving a Web Part is simply a matter of drag and drop, as shown in Figure 1.5, where the My Stocks section is being moved to the lower zone.

Figure 1.5 Dragging a Web Part to another location

Editing of Web Part controls is also part of the portal framework. You can use a control called the WebPartPageMenu to automatically provide a drop-down list where users can change the mode that the page is viewed in and then edit the properties of the individual Web Parts. By default the user can alter a range of layout and appearance properties, such as the title, height, and width (see Figure 1.6).

Figure 1.6 The built-in editing features for a Web Part

Web Parts can also be exported and imported using a standard XML-based dialect. This allows you to share Web Parts between applications. The built-in Catalog features automatically provide a section that allows you to import Web Parts into the current page (see Figure 1.7).

Figure 1.7 Importing a Web Part into the page

Other features of the Web Parts framework allow you to add Help pop-ups to each Web Part, expose custom properties from Web Parts and allow the user to edit these properties, and connect Web Parts together so they can interact. Web Parts is still an evolving technology, and you can expect to see even more features and improvements in the final release of ASP.NET 2.0.

Setting Up and Managing Your Site

ASP.NET 1.x made deployment of Web sites easy with its xcopy deployment model. This removed the need for some administrative tasks, such as registering COM components, but still left other tasks, such as site administration, as more manual affairs. The XML-based configuration file obeyed the xcopy rule, but there are three major problems with it. First, there is no easy-to-use administration tool, meaning you must have knowledge of the XML schema before you can modify it. Second, you need some way to actually fetch the file, edit it, and then upload it. This is a problem particularly for hosted scenarios, where users are always remote, and administration of many sites can become a management nightmare. Finally, you cannot create a Web Application, which is required for sites that require security.

Three features in ASP.NET 2.0 help solve these issues. The first is the Microsoft Management Console (MMC) Snap-in for configuration, as shown in Figure 1.8.

Figure 1.8 ASP.NET Configuration MMC Snap-in

The second feature is a Management API, providing a programmable interface to manage a site. For example, Listing 1.4 sets the authorization mode using the API.

Example 1.4. Setting the Authorization Mode

Dim cfg As System.Configuration.Configuration
Dim authSection As AuthenticationSection

cfg = Configuration.GetWebConfiguration(Request.ApplicationPath)
authSection = CType(cfg.GetSection("system.web/authentication"), _
                      AuthenticationSection)

authSection.Mode = AuthenticationMode.Windows
cfg.Update()

The Management API provides access to all areas of the configuration, both at the machine level (machine.config) and the application level (web.config). This allows utilities to be written not only to manage a single site but also to manage all sites.

The third aspect of site management is the creation of a Web-based tool, wrapping much of the Management API. This provides a simple way to remotely administer a site, as shown in Figure 1.9.

Figure 1.9 The Web Site Administration Tool

Here you have a simple Web interface that allows configuration of all aspects of a site. The interface is designed to be customized, so corporations and hosts can give it a company look.

Using Images on Your Site

Using images isn't a particularly difficult area of site design, but their use has been eased with two new server controls. First, the ImageMap control provides easy support for image maps, as demonstrated in the next code sample.

<asp:ImageMap runat="server"
     onClick="Map_Click"
     ImageUrl="images/states.jpg">
  <asp:CircleHotSpot X="100" Y="100" Radius="25"
       PostBackValue="Other State" />
  <asp:RectangleHotSpot Top="200" Left="150"
       Right="200" Bottom="150"
       PostBackValue="More State"/>
  <asp:PolygonHotSpot Coordinates="3,4, 15,18, 45,18, 15,70, 3,4"
       PostBackValue="State 1" />
</asp:ImageMap>

The detection of the hot spot is handled in the postback event:

Sub Map_Click(Sender As Object, E As ImageMapEventArgs)

  Select Case e.PostBackValue
  Case "State 1"
    ' ...
  Case "Other State"
    ' ...
  Case "More States"
    ' ...
  End Select

End Sub

The second new image-handling feature is that of dynamic images, designed specifically to render images appropriate to the calling browser. This is necessary because images displayed in Web browsers generally aren't suitable for smaller devices, such as PDAs or phones. The newDynamicImage control uses an HttpHandler to sniff the browser type and render the appropriate image. For example, consider the following code:

<form runat="server">
  <asp:DynamicImage ImageType="Automatic"
                    ImageFile="car.gif" runat="server" />
</form>

For a standard Web browser the image is rendered as expected, but for a Wireless Access Protocol (WAP) phone, the image is rendered as a Wireless Bitmap (WBMP). This removes any need for the developer to specifically target images to browser types.

Using Data on Your Site

It's probably no exaggeration to say that most, if not all, Web sites use some form of data to drive them. Whether XML files, a database, or another dynamic form of storage, the data allows a site to respond to the user and to be up-to-date. ASP.NET 1.x provided some great data binding capabilities, but they always involved code, often the same code used over and over. One of the key goals of ASP.NET 2.0 is to reduce code and to ease the use of databases, especially for beginner programmers. To achieve this a new set of data controls has been introduced, removing the need for in-depth knowledge of ADO.NET.

Data source controls provide a consistent and extensible method for declaratively accessing data from Web pages. There are several data source controls, including AccessDataSource, SqlDataSource, XmlDataSource, and ObjectDataSource, and it's likely that others (perhaps for Excel and Exchange Server) will appear as ASP.NET 2.0 nears release, along with third-party data sources. The use of data controls is simple, as shown below.

<asp:SqlDataSource id="ds1" runat="server"
  ConnectionString="server=.;database=pubs;Trusted_Connection=True"
  SelectCommand="SELECT * FROM authors"/>

<asp:DataGrid DataSourceId="ds1" runat="server" />

This just encapsulates the code everyone used to put in the Page_Load event—it connects to the database, fetches the data, and binds the grid. The contents of the SelectCommand can be a stored procedure as well as a SQL command, thus preserving the separation of data access from the page itself. There are commands for updating, inserting, and deleting.

This model is extended by use of a parameter collection, allowing parameters to be passed into the command from a variety of sources. For example, the code in Listing 1.5 automatically takes the value from the TextBox control txtState and feeds this into the parameter @state.

Example 1.5. Using a ControlParameter

<asp:SqlDataSource id="ds1" runat="server"
  ConnectionString="server=.;database=pubs;Trusted_Connection=True"
  SelectCommand="SELECT * FROM authors WHERE state=@state">
  <SelectParameters>
    <asp:ControlParameter name="@state" ControlID="txtState"
       PropertyName="Text" />
  </SelectParameters>
</asp:SqlDataSource>

<asp:TextBox id="txtState" runat="server" />

<asp:DataGrid DataSourceId="ds1" runat="server" />

There are also other parameter types, allowing parameter information to be taken directly from Session variables, Cookies, the Request (Query String), and the HTML Form.

Data Binding

Data binding in ASP.NET 1.x was simple, but it did cause confusion in some areas. For example, should you use early binding, for which you have to know the underlying data structure? Or should you take the development shortcut and use late binding, like this:

<%# DataBinder.Eval(Container.DataItem, "au_lname") %>

With ASP.NET 2.0 this syntax has been simplified:

<%# Eval("au_lname") %>

There is also an equivalent XPath syntax for XPath expressions when binding to XML documents:

<%# XPath("@au_lname") %>

Binding to Objects

One of the most requested features has been the ability to bind data directly to objects. Good design dictates that you separate your data access layer from your presentation layer, and this is often done as a set of classes. The new ObjectDataSource allows you to simply bind directly to existing objects, such as classes, thus allowing you to have a strongly typed data layer but still participate in the easy data binding that ASP.NET 2.0 brings.

Binding to Configuration Settings

A similar binding syntax is used to allow declarative access to certain configuration parameters, such as application settings, connection strings, and resources. Here is the syntax for these:

<%$ section: key %>

For example:

<%$ ConnectionStrings: pubs %>

Internationalization

Building Web sites that support multiple languages is important because Web sites are used by more and more people for whom English is a secondary language. In ASP.NET 2.0 support for multiple languages is extremely simple, based around global resources (sometimes called shared resources) and local page resources. Global resources live in the Resources folder underneath the application root and consist of XML-based resource files (.resx) containing keys and content for those keys. Global resources can be accessed by any page in the application. For example, consider a file called shared.resx, which among the meta-data might have a key like this:

<data name="SharedResource">
  <value>English Label from shared resource file</value>
</data>

There might also be a French language resource file, shared.fr-fr.resx:

<data name="SharedResource">
  <value>French shared resource</value>
</data

Binding to these resources declaratively can be done in the same way as binding to configuration resources, for example:

<asp:Label runat="server" id="MyLabel"
    Text="%<$ Resources: SharedResource %> />

At page compilation time the browser language is detected and the resource selected from the appropriate file.

Another way to fetch this resource is to use a meta-attribute on the label:

<asp:Label runat="server" id="MyLabel"
    meta:resourcekey="Shared:SharedResource"/>

In this case the first part of the meta value identifies the name of the file, and the second part (after the colon) identifies the key.

Local resources are only accessible to individual pages. Like global resources they are stored in .resx files, but this time under a LocalResources directory, where the name of the resource file is the ASP.NET page with the .resx extension applied. Thus for a page supporting two languages there would be two local resource files: LocalResources\UsingResources.aspx.resx and LocalResources\ UsingResources.aspx.fr-fr.resx. Either of the binding formats works for local resources, but generally the meta one is used because Visual Studio 2005 can automatically process ASP.NET pages, adding the meta-attribute and building a resource file.

Adding Mobility Support

Mobile devices are becoming more pervasive. It seems everyone has a mobile phone, many people have PDAs, and some great devices now combine the functionality of both. From the development perspective the problem with these devices is their screen size and rendering capabilities. Not only do many of them not accept HTML, but with their tiny screens some also can't display images, tables, and so on.

In ASP.NET 1.x, the Microsoft Mobile Internet Toolkit (MMIT in version 1.0 and ASP.NET Mobile Controls in version 1.1) provided this support, including separate controls for building Web pages suitable for small-screen browsers. In ASP.NET 2.0, the MMIT is no longer required because mobile support is built into all controls. This reduces the amount of code required as well as the need for specialist knowledge about mobile platforms. This might seem relatively unimportant while the number of sites that target mobile browsers is small, but this is bound to increase as the features of small devices improve and prices drop.

The really important part of the changes is to the infrastructure of the ASP.NET server controls. All controls are now built on a control adapter architecture, where there is an adapter for each specific device. The adapters have knowledge of each device and perform the rendering appropriate for its markup language and screen size. Because the controls are derived from adapters, they don't need to perform any special action to choose what to render—the adapter intelligently renders the appropriate content based on the calling device. New devices are easily supported because they require only the addition of an adapter, which the controls can then take advantage of.

Device Filters

This architecture is taken further by allowing adapter-specific attributes for controls, enabling the page designer to provide different content for specific devices. For example, the following code shows how different text and cascading style sheet (CSS) styling can be defined for a mobile device.

<asp:Label id="MyLabel" runat="server"
           Text="Welcome to our site"
           Nokia:Text="Time to upgrade your Nokia phone!"
   cssClass="StandardStyleClass"
   Nokia:cssClass="SpecialNokiaStyleClass" />
   

Device Templates

Along with modified attributes, we also have the ability to provide templates for specific devices. We know that mobile devices have a small screen size, so repeated controls such as grids and lists either aren't appropriate or need different output. By using specific templates for devices we can now provide different content to different devices, as shown in Listing 1.6.

Example 1.6. Filtered Templates for Mobile Devices

<asp:Repeater runat="server" ..>

  <HtmlBrowsers:HeaderTemplate>
   <table>
   <tr><td>UserName</td><td>Address</td><td>Phone</td></tr>
   </HtmlBrowsers:HeaderTemplate>
   
   <HtmlBrowsers:ItemTemplate>
   <tr>
   <td><%# Container.DataItem("UserName") %></td>
   <td><%# Container.DataItem("Address") %></td>
   <td><%# Container.DataItem("Phone") %></td>
   </tr>
   </HtmlBrowsers:ItemTemplate>
   
   <WmlBrowsers:ItemTemplate>
   <asp:Panel runat="server">
   <%# Container.DataItem("UserName") %>
   <%# Container.DataItem("Phone") %>
   </asp:Panel>
   </WmlBrowsers:ItemTemplate>
   
   <HtmlBrowsers:FooterTemplate>
   </table>
   </HtmlBrowsers:FooterTemplate>
   
   </asp:Repeater>
   

These mechanisms provide a way for developers to override the built-in rendering for mobile devices. Along with automatic mobile support with the standard controls, there are controls specifically designed for mobile devices, such as PhoneLink (to launch a phone call) and Pager (to provide paging support). Standard controls also support the SoftKeyLabel attribute to allow specific text to be targeted to soft keys on phones.