What is DotNetNuke Skin Design?
DNN Skins are themes found in DotNetNuke, which control the look and feel of a page in DotNetNuke. DotNetNuke Skins were first created to make skinning available to both designer and developers. Most themes contain CSS and HTML that are usually used to structure pages. DotNetNuke skins have a minimum of one pane that is referred to as the ContentPane. They also have multiple panes. On top of panes, the skin can hold whatever custom HTML/Javascript that is required, such as a typical web page. Skin objects can also be included in the skin or any pane. They are tools that provide rich content for essential items, e.g., Search bar, menu, banners, copyright.
DotNetNuke Skinning Engine
There are two skins supported by the skinning engine: ASCX skins and HTML skins. HTML is the most basic form of skin, and it gives designers the liberty to use whichever HTML editor they wish. HTML skins are converted to ASCX skins in the background when they are installed. Only the InnerHtml, which is a part of the HTML skin is retained during the conversion.
DotNetNuke Skin Design Terms
A skin is made up of at least one layout template. Each skin may also have a style sheet for each named template and a master CSS style sheet. If a stylesheet is present, the DotNetNuke skinning engine will add them to the page whenever the skin template is assigned. As we are building individual layouts for our skin, it is important to determine where we want to place user generated content and where standard skin elements will be placed.
Other than panes, there are some elements that our skin design has, which are fairly common across designs. These elements include the menu bar, login/registration links, copyright notice, terms of service link, search box and others. These elements, in DotNetNuke are added to the page by Skin Objects.
Creating Custom DotNetNuke Skins
1. One of the hard and quick rules of DotNetNuke skinning is that all skins should have at least one content pane. The pane should be called Content pain. You don’t have to have any style sheets or other files.
2. When the DotNetNuke website installs the skin, it's parsed, and the body tag's inner HTML is converted to ASCX control. Once the file is converted to ASCX, the original HTML ceases to be of use. As long as you are comfortable with the ASCX file, you may start working directly with it without having to build an HTML version.
3. The new skin would have to get installed into a DotNetNuke installation for it to be tested.
4. Since the skin is in the right location, DotNetNuke should be opened up and used to convert the skin to ASCX format and assigned to the page.
5. Use a super account, host account, to login to DotNetNuke. Only those with Super User access can parse HTML templates or upload new skins. This is because skins may contain code that is only executable on the server.
6. When logged in with a super user account, locate the Admin menu and go to the skins page. Administrators and Super users can manage different containers and skins available for an installation or a single portal without installation.
7. Select a skin from the skins dropdown and choose the link "Parse Skin Package." There will be text outlining the parsing steps. You will then find a new file in the skin folder.
Common DotNetNuke Skinning Engine Misconceptions
Over the years, designers have had frustrations with the DNN skinning engine, most of which have been misunderstanding. Below are some of the common misconceptions:
All the DotNetNuke sites look the same
Some users say that DNN sites all look alike and have the same basic layout. This may have been true before, when the designers were learning how to work the skinning engine. Now, however, the only reason that DNN Skins may have the same layout is that many designers have become accustomed to standard layouts that work well for particular website categories. Designers, however, have freedom in choosing whatever design they may please to create stunning designs.
DotNetNuke Designs aren’t XHTML COMPLIANT
DNN skinners are in complete control of the markup generated by containers and skins. As long as the Skins conform to XHTML, HTML 4 or HTML 5 standards, the designer is free to create skins. The one constraint, though, would be the choice of skin objects used and the modules placed on the site.
DotNetNuke design has to have tables as the layout
Many skins use tables for structural purposes. However, the choice to use a table is entirely under the skin developer's control. In reality, table-less cases are more fragile that the designs that use even a small table. If you don't want to use a table, you are at liberty not to do so.
Their skins are difficult to create
This isn’t so because the DNN skinning engine is flexible and gives control over the design. Simple DNN designs are relatively easy to achieve. However, as the designs become more complicated, so will the corresponding skins. It isn't a DotNetNuke characteristic, but rather a design aspect. Because the DNN skins are generally CSS and HTML, designers who have a better understanding of CSS and HTML will have it easier when converting their designs to skins. Getting a skin packaged for distribution is actually the most complicated bit of skinning. This particular point hasn't been documented well in the developer docs.
DNN menus don’t use semantic markup
This point may have some truth to it but in a minor sense. The default DNN menu provides menus using JavaScript, which subsequently provides the menus via a series of tables. Many designers don’t care for this menu. However, there are many menu options that a developer can choose from when creating skins.