As DotNetNuke has grown and aged the methods of skinning for the framework have continued to age and improve. With the pending release of version 5.1 of DNN about to happen, I thought it would be nice to put together a series of blog posts about the methods and types of skinning options available.
The options for skinning DNN have grown considerably since version 1.0 of the product. With 1.0 you had to actually change the skin within the codebase and it wasn’t a very easy task at the time.
When 2.0 was released, one of the important features of that release was the ability to easily update and change skins. At least if my memory serves me correctly. I know by the time 3.0 was released skinning had been basically standardized in how it was going to be accomplished.
At this point forward till the release of the 5.0 product, not a lot had changed in how skinning was done within the framework. We had two options when it came to skinning, I’m going to call the two methods we had up to this point the web designer way and the the web developer way.
Let me explain what I mean, the web designer way consisted of using html, css and xml files to provide the markup, style sheet information and the xml file tied them together with the skin objects that were available within the framework that it was being installed on.
The web developer way consisted of using ascx and css files to accomplish the same thing. The main difference is that as a web developer, the properties of the skin objects were placed within the ascx file instead of the xml file. The other main difference is that using the ascx and css file combination the file wasn’t changed when it was uploaded to the framework.
With the release of version 5.0 of the framework, there was an introduction of a 3rd method of creating skins with the use of skin widgets. As well as some new methods of packaging up your skin for public release has changed with the new version. We still have support for the older way of packaging up skins in zip files without an xml manifest, but there is a new way that allows us to provide more information as well as the ability to write release notes and to provide a license for the use of the skin.
Over the next several blog posts I will go into detail and build a skin that will take will be the same but built in the three different ways that we have available. As well as a post about the new method of packaging up a skin for the latest release of the framework.