RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Skin Your Web Apps Using MVC : Page 4

The Model-View-Controller architecture, built into ASP.NET, lets you drive a different look to your ASP.NET pages using the same code base.

Practical Application
When you apply this technique to a Web application, you need to incorporate a way to choose a skin when you architect your site. Naming conventions will play an important part here since part of the form's name may both describe it and designate the skin's name.

For example, you may want to determine what skin to use when a user enters the application. You may store the name of the skin in a cookie so that it's easily accessible throughout the application. Suppose you have two skins named "Summer" and "Winter." The site can then have several views of each Web Form, which can represent Home, MemberList, MemberEdit, Admin, and ContactUs. The names of the ASPX pages that represent each of these views can incorporate both the view and skin name in its page name. Thus you might have Home_Summer.aspx, Home_Winter.aspx, MemberList_Summer.aspx, and MemberList_Winter.aspx. Redirection to any of these pages might require you to take the name of the chosen skin, combine it with the name of the view you want to display, and add it to an actual page name to transfer to.

Not Just for Pages
Figure 5: A Warm Skin
ASP.NET introduced User Controls, which allow you to break your pages up into more reusable parts. User Controls use the same architecture that Web Forms do. They have an HTML side (.ascx files) and a corresponding code-behind file. The ASPX pages have a similar directive located at the top of the page called the @Control directive, which serves the same purpose as the @Page directive used in Web Forms. For this reason, the skinning technique I'm showing you here is totally applicable to User Controls as well. In fact, when you're designing a Web site that would use this technique to provide skinning functionality, you would more than likely use dynamically loaded User Controls throughout the entire site. Figure 5, Figure 6, and Figure 7 show three different User Controls used in a page, each with a radically different look, but each driven by the same code-behind class.

Code Organization
When I design a new system, one of the things I take pretty seriously is the organization of my code. While many developers take their code organization for granted, it can be pretty critical when you're discussing driving several pages from one code set.

Figure 6: A Cold Skin
As I showed you earlier, once you've accomplished hooking up one code-behind file to more than one Web Form (or User Control), when you bring up the code-behind module, you will see its file move under the most current Web Form. If you do not wish to see your files move around like that, you can physically move the code-behind files to another location within your project (preferably under their own folder). This can help you keep your Controllers organized in one place. I think this technique probably make a little more sense since you want to use them to drive more than one View. If you still want to make your code-behind files accessible by double-clicking on a control on any of its Web Forms, just change the CodeBehind= argument in the @Page directive to follow the path you moved the files to. If you leave out the CodeBehind= argument altogether, you will need to access the code-behind files directly from the Solutions Explorer.

Taking Code Separation to a New Level
Skinning accomplishes a goal that VB 6 Web Classes attempted but didn't quite perfect until the release of .NET. Skinning allows for true and total code separation, allowing the UI developer to work completely independently of the developer working on logic code. This kind of developer separation was of course possible between layers, but now you can accomplish the same within the presentation layer as well. Of course, this may not be the course your company decides to follow for a project, but the choice is there nonetheless. If you do wish to make this separation absolute, you can go as far as to move the code-behind files into another project, and reference them from your Web project. In this case, you would definitely eliminate the CodeBehind= argument from the @Page directive completely. You can then have one group of programmers working on purely the HTML page and the only extra knowledge they would require is which ASP.NET server controls the pages need and what their declarations are. The developer working on the code-behind class does not care what the HTML looks like. He or she can simply rely on the existence of a certain group of Web Server controls.

Figure 7: A Black and White Skin
Whether you decide to keep the code-behind files within the Web project or separate them out, you can also rename them to whatever you want. Remember that by default, a code-behind file name is the name of the original Web Form it drives with a .vb or .cs suffix. You don't have to follow this naming convention and it is perfectly feasible to change such names if the code-behind files drive more than one Web Form.

Skinning techniques requires a bit more work than simply changing style sheets, but skinning provides ultimate flexibility to design radically different looks for pages with the same functionality. You must use your best judgment as to where to apply to and how to set up your development process. You can get really creative and combine this with style sheet variations for the ultimate Web skinning. Due to the nature and structure of this article, I didn't find it particularly useful to include source code within the article itself; however, you can download the source code accompanying this article. My code demonstrates not only the Web Form examples, but also an example skinning User Controls with three radically different themes (as shown in Figure 5, Figure 6, and Figure 7). Have fun with this; with a little effort you can provide a rich experience to users of your Web applications and eliminate the monotony they may feel over using the same pages for a long period of time.

Miguel A. Castro is President of InfoTek Consulting Group, Inc., a professional consulting firm that specializes in architecting, designing, and developing solutions using Microsoft .NET technologies. His VB background goes all the way back to 1.0. Miguel's focus for the last couple of years has been the .NET Framework and languages; he is fluent in both VB .NET and C#. His programming experience goes back 20 years when he started on TRS-80s, Apple IIs, and Atari 800 computers. Miguel lives in Lincoln Park, New Jersey with his wife Elena and his daughter Victoria.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date