Customizing and Managing Your Site's Appearance / Page 4

[previous] [next]

Customizing and Managing Your Site's Appearance (con't)

How Themes Work

Now that you have seen how to create and use themes, let us peek under the hood and examine what ASP.NET does to make themes work. Like everything in ASP.NET, it all begins with a request. When a request arrives for a resource from an ASP.NET application that uses themes, the runtime parses and compiles all the skins in each theme. Recall from Chapter 2 that the markup in an aspx page is parsed into a class and then compiled into an assembly; an analogous thing happens with the skin files—each theme is parsed and compiled into a separate assembly.

Each theme is realized as a concrete subclass of the PageTheme class. This class maintains a collection of ControlSkinDelegate objects. This delegate represents or "points to" the actual method that applies the correct skin to the control; this method exists in the class file generated for the skin.

When the runtime executes a page that has a theme, it iterates through the page's Controls collection, and if there is a delegate for the control type, it calls the delegated method (in the generated skin class) which then decorates (i.e., changes the properties specified in the skin) the specific control object.

Overriding Themes

As previously mentioned, skin definitions for a control type override any settings for that control type made within a given page. For instance, consider the following skin definition.

Now imagine that you use this skin in a page that contains the following markup.

What text color will the content of these two Label controls have when rendered by the browser? In fact, both will be green, because skin definitions override page definitions. You can have a control ignore a skin setting via the EnableTheming property, as in the following.

There is another way to have properties defined within individual controls override skin settings. You can do so by changing the Page directive of the form and use the StyleSheetTheme attribute rather than the Theme attribute. Unlike those applied by the Theme attribute, the properties applied by the StyleSheetTheme are overridden by control properties defined within the page. As such, the StyleSheetTheme behaves in a manner more akin to the cascade within CSS. For instance, in the following example, the "World" text is blue.

You can also set the StyleSheetTheme via the Web.config file. To set it in the Web.config file, you would use the styleSheetTheme attribute (rather than the Theme attribute), as in the following.

Other than the fact that one allows skin properties to be overridden and the other does not, what else is different between the Theme and StyleSheetTheme attributes? A Theme is applied after the properties are applied to the server-side control, which is why the properties set by the Theme override those of the control. A StyleSheetTheme is applied before the properties from the server-side control, and are therefore overridden by the properties on the control. As well, the Visual Studio designer displays skins set by the StyleSheetTheme, but not by the Theme. If you specify both a Theme and StyleSheetTheme, the Theme takes precedence (i.e., control properties are overridden by the theme).

So which should you use? StyleSheetTheme is probably ideal during development because the Visual Studio designer displays the skins, and you can make quick changes to the page's Web server control appearance properties as part of your debugging and development. But because one of the primary benefits of themes is that you can change the entire appearance of a site through one simple theme change, it probably makes sense to use the Theme property when your site is ready for deployment; by then, you will no longer need the designer support and you will probably want to override any page properties by the formatting specified by the individual skins.

Named Skins

If you need to override the appearance of a skinned control, perhaps a better approach than using StyleSheetTheme is to use named skins. For instance, you might not want all of your Label controls to have the same appearance. You can thus define alternate skin definitions for the Label control by giving the different skins separate SkinID values. You can then reference this SkinID in your Web Form's Label controls. For instance, let's define a skin file with the following content.

To use the named skin in any of your Web Forms, you simply need to add the reference to the SkinID in the controls that will use the named skin, for instance:

In this case, the word "Hello" appears in bold, 14pt red Verdana, whereas the word "World" appears as 10pt green text.

Themes and Images

One of the more interesting features of themes is that a given theme folder can also contain images and CSS files. You can thus radically transform a Web page by substituting different images and different style sheets. For instance, different themes could use a different set of images for bullets, image buttons, or for the icons used by the TreeView control. The only requirement is that the skin must use a relative URL for the image. This means that the image files must exist somewhere inside the same themes folder as the skin file itself.

For instance, the following skin defines two controls. The first is a named skin that displays the masthead image for the site; the second defines the look for all BulletedList controls. The relative path for the images indicates that the files are contained in a subfolder named images within this particular theme folder.

To use this skin, your Web Form might look like that shown here. Notice how the resulting code in the Web Form is quite simple, because the additional properties are contained in the skin rather than in the Web Form. Figure 6.6 illustrates how the visual appearance of this form might vary simply by having different images for logo.gif and bullet.gif in two different themes containing the exact same skin.

[previous] [next]

URL: