Skinning

One of the things which is hindering the completion of the DNN 2.0 code is implementation of the skinning solution. It is imperative that we deliver a skinning solution to the community in this release but there are a number of complications to consider.

1. The ASP.NET V2 "Whidbey" release contains a number of UI related enhancements which need to be considered for future upgrades. They have a concept known as Master Pages which is NOT a skinning solution - it is a templating solution and works on the premise of a pre-defined page layout ( our free-form skinning is not based on a pre-defined page layout ). They also have a concept known as Themes which is similar to CSS style sheets but allows you to apply a set of display properties to your server controls ( as long as they support the new SkinId property ).

2. The free-form skinning approach requires the isolation of all UI elements. This means the composite desktopportalbanner and desktopportalfooter user controls have been broken into their individual parts so that specific elements can be placed anywhere on the page. The complication here is that the composite user controls must be maintained for legacy purposes - there are custom modules which contain ASPX pages that rely on these controls.

3. The free-form skinning approach also relies on a single ASPX page so that skinning is applied consistently across all user interfaces. This means the functionality of the old EditModule.aspx page has been merged with the DesktopDefault.aspx page. Once again we run into legacy support issues as there are many modules which rely on the existence of EditModule.aspx. The best suggestion to deal with this is to include it as a stub page which simply reformats the URL and redirects to the new DesktopDefault.aspx page.

4. Free-form skinning is complicated by user interface elements which are hard-coded. Examples include the current signin.ascx and the admin bar displayed when the administrator logs in. In a perfect solution there should be no hard-coded UI elements; therefore, modifications need to be made to deal with these.

5. There has been a lot of discussion on file system naming conventions - Themes or Skins? The Alpha release of ASP.NET V2 reveals that the Microsoft approach relies on the existence of a Themes folder beneath the application root. And when it comes to individual skins, we have toyed with GUIDs, IDs, and Names. ASP.NET V2 uses a unique skin name for the directories beneath the Themes folder. This eliminates the dependency on a database which means you are free to upload your skin file outside the application ( ie. via FTP ). However it also exposes the potential for naming conflicts.

6. A further item also relates to the physical organization of skin files. In DotNetNuke we have multiple portals. Each portal administrator will need the ability to manage the skins for their own portal. Therefore it would seem that the \Themes folder should be