Customizing and Managing Your Site's Appearance / Page 5

Despite the benefits of CSS, there are several things that skins can do, which CSS cannot. Some server control properties that are themeable have no CSS equivalent. For instance, you can specify the textual format to display the days of the week in a Calendar control or the locations for the hot spots in an ImageMap control. As well, because themes are applied on the server side, it is possible to dynamically specify a theme based on user input or configuration information without the bother of Javascript-based CSS file swapping.

In addition, the more complex templated controls, such as Calendar, GridView, MultiView, Wizard, and so on, are probably styled more easily through skins, because it is up to ASP.NET to determine exactly what markup to use when rendering these controls. Yet even here, there still is a role for CSS. For example, in the following GridView skin definition (we cover the GridView control later in Chapter 10), the three style templates contain appearance properties.

A better approach is to define the template styling information via CSS classes.

With the CSS classes defined, you could then simply reference these classes in the skin, as shown here.

Again, the benefit of this approach is that the typical Web designer, who probably does not know ASP.NET, can still make changes to the visual appearance of the ASP.NET application by modifying the appropriate CSS files.

Dynamically Setting the Theme

One of the key benefits that themes provide to the Web developer is the ability to programmatically change a page's theme. A page's theme can be set programmatically in the code-behind class. However, you may recall from Figure 2.3 in Chapter 2 that theme skins are applied before the controls and page are initialized. Thus, you must set the page's Theme property in the PreInit event handler for the page, as shown here.

The PreInit event is new to ASP.NET 2.0. It is raised just before the Init event of the page, but after the controls for the page have been instantiated. Of course, with the simple example shown earlier, it makes much more sense to simply set the theme in the Web.config or in the Page directive. The real advantage of using the programmatic approach is that the page's theme can be set dynamically based on user preferences. This preference can even be persisted in a user profile (covered in Chapter 14), in a session (covered in Chapter 12), or in a database.

Like with the Theme property, you can also set the StyleSheetTheme property programmatically. However, unlike with setting the Theme property, the programmatic setting of the StyleSheetTheme property is not done in the PreInit method, but is achieved by overriding the property in your code-behind class, as in the following.

Setting the theme dynamically based on user input is not quite so straightforward. The problem lies in the fact that the theme needs to be set in the PreInit event of the page, which is before any of the controls have had their values loaded from the view state or the form input data. For example, imagine a page with a drop-down list by which the user can select the theme for the page. The list would have an event handler that would process the user's theme selection, but unfortunately you cannot set the page theme in this event handler. It has to be set before the postback event handling in the page's PreInit event. Yet during the PreInit event, you cannot yet know what the user selected!

The solution to this conundrum is that you need some way to store the user's theme selection in a way that is available to the PreInit event, and then reload the page so that the PreInit event is invoked again. How then can you store the user's theme selection? Later in Chapter 14, you will learn about the user profile system, which could be used for this problem. An alternative we will use here is to use ASP.NET session state (refer to Chapter 12 for more detail).

Session state allows you to store and retrieve values for a browser session as the user moves from page to page in the site. Recall that HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request and retains no knowledge of code-behind data members or form values used during previous requests. ASP.NET session state provides a way to identify requests received from the same browser during a limited period of time and provides the ability to persist values for the duration of that session.

ASP.NET session state can be accessed from an ASP.NET Web Form via the Session property of the Page base class. This property references an object collection that is indexed by name. When you save an object in the session collection, you identify it by using a name, which can be any text string that you want. You can thus use session state to save the user's theme choice in the list event handler, as shown here.

Notice that retrieving the theme name from the session collection requires a casting operation (from object to string). Also, the method cannot assume that the session collection actually contains a theme name. It might be the first time the page has been requested and thus the theme does not exist yet in the session. Alternately, the session may have timed out and thus is empty. For this reason, any time you retrieve an item from session state, you must always verify that the item does exist, typically by comparing it to null.

Printed with permission from from the book Core Internet Application Development with ASP.NET 2.0 written by Randy Connolly. ISBN 0321419502 • Copyright © 2007 Prentice Hall..

Digg This Add to del.icio.us

URL: