Don't you just love euphemisms? Back in good old days I remember using the term "page-styles" or even "looks." Later, Windows itself introduced the concept of Themes. It seems that the term-du-jour is skins
Skinning is the ability for your Web (or Windows) application to change the layout and look of its pages or forms to suit a user's desire. There are different ways to achieve these kinds of results, and the technique (or combination of techniques) you choose to use depends on the extent and versatility of the skinning you wish your application to have.
One of the more common ways to provide some amount of skinning to your apps is to use style sheets. Style sheets are great and of course are the preferred way of providing any formatting for your Web pages, but they do have their limits. The HTML elements of Web server controls can have style sheet elements assigned to them in order to provide their formatting. You can provide many different style sheets that contain the same named elements and provide your application with a way to switch between them. This will give you a lot of variety in formatting and even positioning, but nothing as radical as varying the graphical images on the page in combination with varying positioning, all with WYSIWYG design-time functionality.
Suppose you want to display different graphics on the page or have one skin display square boxes as its panels while another displays rounded boxes. Or even provide completely different layouts and positioning for all screen elements? How about one skin with the menus across the top and another with menus on the side? One skin may be a winter theme with snow images around all the panel boxes housing text and controls, while another skin can be a summer theme with sunshine and beach images all over the place. As you can imagine, the possibilities are endless and extend way beyond picking a Desert, Eggplant, or Rose theme as Windows lets you do. The technique I'm going to show allows you to do all of this.
Now, keep in mind that with this kind of power and flexibility comes more work. I think it's pretty obvious that creating a skin is a little beyond just coming up with a new style sheet and changing some color, font, or size codes. I do think, however, that the work is well worth it if you're looking to provide the most extensive skinning available to your sites. In the end you will have to use your best judgment to balance the time, cost, and necessities in your projects when deciding how much skinning flexibility (if any at all) to bring to your sites.
A Little Known Secret
I hope I won't insult anyone's intelligence with this information but you would be surprised how many do not know what I am about to explain here.
You probably have noticed that when you view your code files in the Solutions Explorer, you usually only see the Web Form pages (the .aspx files) listed, and not the code-behind files. Look at the button at the top of the Solutions Explorer whose tool tip says "Show All Files." Click this and you will see all your Web Form files show a + sign to their left. If you expand these, you will see each Web Form's corresponding code-behind file (as well as the .resx resource file). You're going to need to show all files in order to continue with what I am about to explain.
Basically it boils down to a very simple thing: driving more than one ASPX page with a single code-behind class. I'm going to cover a few guidelines in order to make sure that your implementation of this technique goes without any flaws. In order to realistically illustrate each step, let's refer to an actual Web Form called MemberList1.aspx
. If you create a Web Form like this one and press the "Show All Files" button on the Solutions Explorer, you will see two files appear: MemberList1.aspx.cs
(let's assume you're working in C#, but of course the VB counterparts would end in .vb
). Now let's assume that your Web Form has two Labels, two TextBoxes, a DataGrid, and a button. Using techniques I'm sure you are already familiar with, you can make these five controls look any way you wish, either by direct styling or using cascading style sheets. You can, of course, position these controls wherever you want on the form. If you view the code-behind for your new Web Form, either by clicking on the View Code button at the top of the Solutions Explorer, or by double-clicking the newly exposed MemberList1.aspx.cs
file, you can attach code to any or all of the five controls. So let's style up the controls on the form and assign some data to the textboxes from the code-behind page. You'll also trap the button's Click event and fill the DataGrid. The styling used in the page can be anything you wish. In the ASPX page shown in this article, I used style sheet classes that I attached to each control on the Web Form. Though this is the preferred method of Web styling, you can use hard-coded font tags if you wish (see Figure 1
There's probably nothing here that you haven't seen or done before. In fact, you may be saying, "Get to the point, already." Well, you see, I love this stuff too much to skim through it quickly, so I purposely dwell on the obvious in order to absorb the beauty that is the code. If you run this page you'll see your two textboxes filled with the text that was placed in them in the code-behind page. If you click on the button, the DataGrid will display three rows of data. All this data gets loaded in the code-behind page. Now it gets interesting: let's add another Web Form called MemberList2.aspx. This form will have the same controls as MemberList1.aspx, but this time let's lay them out in a completely different arrangement (see Figure 2).