Article
About the Author
Philip Miseldine
Philip is a Computer Science PhD student at Liverpool John Moores University. He's still not mastered guitar tabs, never finished Mario, and needs a haircut. He discusses life at http://www.miseldine.com/.
Prepare Yourself for Whidbey
The dust has settled after the much-hyped Microsoft PDC, where the future of Windows and .NET was announced and current progress was demonstrated. For developers, this means a whole new set of acronyms and technologies to become familiarized with, and, hopefully, a little excited about too. The purpose of this article is to give the ASP.NET developer a chance to prepare for what's coming to .NET in the near future.
Whidbey: What is it?
Whidbey is the code name for the next generation .NET tools and technologies. Think of it as .NET 2.0. While still in Alpha release, Whidbey is already chock-full of additions, simplifications, and useful helpers.
While this article will concentrate on the biggest benefits introduced for the average ASP.NET developer, there's more to Whidbey than I can cram into this short space. Those interested in further information should keep an eye on the official Website, ASP.NET as well as MSDN.
Master Pages
One of the biggest problems Web developers face is how to abstract the layout and appearance of a Web application. Custom base Web form classes and user controls introduced in ASP.NET certainly helped, in so far as allowing for custom UI elements and page types to be developed and integrated into pages. The placement and layout of page components, however, needs to be replicated across all an application's pages, meaning a lot of manual alterations are required to rework the overall look of an application.
ASP.NET 2.0 introduces master pages, a straightforward and powerful mechanism for templating an application. As the developer, you can create a master page; that is, a page that defines the placement and appearance of elements comprising the pages in your application. Content pages then (as the name suggests) actually define the content and data to appear on the page. This information is then merged with the master page when a request is made, and a completed page is served up:
Where ASP.NET actually places your content is specified by you on your master page using content placeholders. Let's look at a simple example that shows this in action.
Below is the code for a very simple master page:
<%@ Master Language="C#" %>
<html>
<body>
<asp:ContentPlaceholder id="textContent" runat="server">
</asp:ContentPlaceholder>
</body>
</html>
There are two items of interest here. First, we tell ASP.NET that this page is a master page through the attribute Master in the page directive. Second, we define a content placeholder, called textContent. Anyone who's familiar with server controls will see that a content placeholder can be treated in just the same fashion as existing server controls.
In effect, a content placeholder is a region of the page that we can fill with content defined in a content page. We can link into the placeholder whatever controls we wish to include, and the completed page will inherit all the layout styles and markup defined in the master page. Below is a content page that adds a label control with the text "Hello World!" at the placeholder called textContent:
<%@ Page Language="C#" Master="~/sitepoint.master" %>
<script runat="server">
void Page_Load(object sender, System.EventArgs e)
{
lblText.Text = "Hello World!";
}
</script>
<asp:Content id="Content1" ContentPlaceholderID="textContent" runat="server">
<asp:Label runat="server" id="lblText"></asp:Label>
</asp:Content>
To link the page to use the master page we defined earlier, we add the attribute Master to the page directive to identify the master page (saved in this example as sitepoint.master).
We then define the content we'd like to display inside the content placeholder on the master page. To do this, we use a new server control, content, and set its ContentPlaceholderID attribute to the ContentPlaceholder we wish to use. In the case of our example, the ContentPlaceholder in question is called textContent.
Among the events on the content page (like Page_Load), we then access the Label control we've defined to be added into the content placeholder just like any other control. Here, the Text property is set to "Hello World!":
void Page_Load(object sender, System.EventArgs e)
{
lblText.Text = "Hello World!";
}
The real beauty is that, if we wished to change the look of our pages now, all we'd need to do is to alter the master page; in effect, the layout has been abstracted from the content of the pages in our application.
Multiple Device Master Pages
ASP.NET 2.0 also allows you to define different master pages for different calling devices. If the visitor uses Mozilla to view your site, you can define a master page which will render correctly with Mozilla; ditto with Internet Explorer; ditto with a WAP browser. Finally, multi-device applications can be developed and centrally managed without any fuss.
Just as we linked a content page with a master page in the above example, we can also define master pages to use based on the calling device:
<%@ Page Language="C#" Master="sitepoint.master"
Mozilla:master="mozilla.master" %>
Depending on the requesting device, the appropriate master page is linked to the content page. This is particularly useful when writing client-side code that may not be cross-platform compatible, for example, some DHTML menus or JavaScripts.
Themeing
But the control ASP.NET 2.0 provides us over the creation of a uniform look and feel doesn't stop there. Enter: themeing, or skinning, as it's popularly known.
Using skins, you can dynamically alter the appearance of controls on your form using a skin file. A skin file can define both the default appearance of controls and the specialisations of those controls, much in the same way CSS works today. However, unlike CSS, themeing allows you to set values for any property of an ASP.NET server control, including data-binding properties, as long as they're theme-aware.
Below is a skin file that sets both the default appearance of a Label and a specialisation of a label control. We can access this specialisation by setting the skinID attribute of a control appearing on the pages in our application to equal the ID of the specialisation.
<!--DEFAULT -->
<asp:Label runat="server"
Font-Names="Arial" Font-Size="12pt"
ForeColor="#ff0000" BackColor="transparent" />
<!--SPECIALISATION -->
<asp:Label runat="server" SkinID="Title"
Font-Names="Arial" Font-Size="18pt"
ForeColor="#0000ff" BackColor="transparent"
Font-Bold="true" />
If we now specify that we wish to use this skin file in our code, all label controls will inherit their appearance from the default we've specified in the skin (that is, size 12 red Arial font). Yet if we set the skinID of a Label control on our form to equal our specialisation, named "Title", the specialisation appearance will be used.
Let's see how we can use this skin file. Below is the code for a form that uses the skin (saved in the directory Themes/MyTheme) to control the appearance of its controls:
<%@ Page Language="C#" Theme="MyTheme" %>
<asp:Label runat="Server" SkinID="Title"
id="titleLabel" Text="This is a title!"/>
<p>
<asp:Label runat="Server"
Text="This is the default text"/>
</p>
The first label inherits its look from our specialisation Title, whereas the second label inherits its look from the default defined in our skin file, and thus, does not require a skinID property.