I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Building a Skin

In Part 1 of this series I looked at some of the fundamentals of creating skins for DotNetNuke.  In this post I will walk through creating a complete skin based off the design I downloaded from OSWD.  The original OSWD design does not include several key elements that are quite common for modern websites, especially websites built with Content Management Systems.  As I progress through this post, I’ll point out when we deviate from the original to address some of these issues.

This article is cross-posted from my blog on DotNetNuke.com.

Ever since the localization framework was first introduced in DotNetNuke 3.0, it has always been our intention to go back and complete the localization story for DotNetNuke.  When localization was...

I am pleased to announce the release of DotNetNuke 5.4.4.  This maintenance release resolve’s two significant breaking changes that slipped through in 5.4.3 and resulted in us pulling the 5.4.3 release. Below are the highlights from this months release. As usual, you can see a full list of changes in the changelog.

Major Highlights Fixed issue with ExecuteSql method overloads to be able to handle ExecuteSQL(string,...

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Understanding the Basics

In the first part of this series we’ll be covering the basics of DotNetNuke Skinning.  My intent is to demystify some of the terms that we use and to relate them to our simple design.  Once you understand the basic elements that make up a DotNetNuke skin, then the rest of the skinning process becomes very easy.

A Little Background

One of the original goals we had when the DotNetNuke skinning engine was first created in 2003 was to make skinning accessible to both developers and designers.  This fundamental requirement has driven many of the changes over the years and continues to shape how we think about skinning in DotNetNuke.  From the very outset we thought that it was important that skin developers should be able to use whatever tool they were comfortable with and that they should not require any knowledge of programming in order to create cutting edge designs.  We also thought it was important that we put as few restrictions as possible into the skinning engine which would provide skinners with complete freedom in their designs.

The DotNetNuke skinning engine supports 2 different types of skins:  HTML Skins and ASCX Skins.  HTML Skins are the most basic form of skin and allow designers to use whatever HTML editor they desire.  When HTML skins are installed in DotNetNuke they are automatically converted to ASCX skins in the background.  During the conversion, the only part of the HTML skin that is retained is the innerHtml of the body tag.  Anything in the HTML Header will be discarded.

The DotNetNuke skinning engine recognizes a “Skin” as having two distinct entities: skins and containers.  These elements can be packaged and installed as a single package or as two distinct packages.  We’ll discuss containers later in this series and for now will focus on just the main skin package.  All of the concepts translate directly from skins to containers with a few minor differences.  If you understand how to create a skin, then creating the associated containers is easy.

Today Microsoft opened up the beta for Wave 4 of the Windows Live Essentials tools including Windows Live Writer.  I have been a long time user of WLW and have come to really enjoy both the simplicity and the power of the tool when writing my blog posts.  I really didn’t see a lot that needed “fixing”, and in this release of WLW it looks like that is exactly what I got – not a lot that has been fixed.

That is not to say that a lot hasn’t changed, because from a UI perspective, it is almost completely different.  The biggest change is that the new live writer now proudly sports a fairly standard ribbon bar just like those found in Microsoft Office.  And just like in Office, I find that the new ribbon bar is somewhat of a step backward.  People are by their natures creatures of habits.  Once we learn how to do something, we don’t want to have to relearn it without a very good reason. 

This morning I updated the source code for the Silverlight Pages module that I am building as part of the DotNetNuke Hackathon.  Based on some feedback from Michael Washington, I did a little refactoring to separate out my XAML display markup into a separate view.  This makes the code just a little bit cleaner and allows me to develop the view in Blend (of course that is a whole new thing to learn which will have to wait for later).  For now I will continue to hack away in XAML, learning a bit more each day and shaking off some of the cobwebs from what I had learned 2 years ago.

There are a number of cases in programming where you are often forced to store data in one format but need to convert that data to a different format for display.  One of the situations where this seems to come up quite often is in the storage hierarchical data structures.  SQL Server has traditionally had very poor support for dealing with hierarchical data.  SQL 2005 and 2008 have made some effort to try and simplify solving this problem, unfortunately, there is still a lot of data that is stored in a format that is not readily able to take advantage of these new SQL Features.

When working with legacy data, or legacy business tiers which expose the data as flat collections with ID and ParentID fields, you will likely need a simple way to convert these records into some form of nested collection.  This is a problem where people often resort to brute force methods for doing this conversion.  Unfortunately, the brute force approach is often slow and very specific to a specific set of data.

 

As part of the DotNetNuke Hackathon at the Capital DotNetNuke User Group on June 16th, I discussed using Silverlight to create rich DotNetNuke modules.  The example that I presented was a work in progress which I’ll be working on during the course of the Hackathon, even as participants are working on their own submissions.  You’ll be able to follow along with my progress over the next few days as I continue to flesh out the module.

The module that I am working on is a Silverlight based replacement for the core Pages module that appears on the Admin menu of a standard DotNetNuke installation.  That module has a very basic UI that makes it difficult to manage a site with dozens or even hundreds of pages.  The postback model used for moving pages in the heirarchy can make page re-organization...

I am pleased to announce the release of DotNetNuke 5.4.3.  This month’s maintenance release focused on resolving major issues with page management and with the Telerik HTML Editor Provider.  The page management fixes should resolve all major outstanding issues in this area.  The HTML Editor Provider fixes addressed some of the larger issues with the provider, although we recognize there are still several fixes and enhancements that remain for this particular item which we hope to address in the upcoming 5.5 release.  The 5.4.3 release also includes a number of security fixes.  As always our community continues to work...

In May, Nik Kalyani traveled to the Orlando DotNetNuke User Group to present the first DotNetNuke Hackathon event.  The Orlando Hackathon was very well attended and focused on teaching developers about the new MVP design pattern and the WebformsMVP framework that was included in DotNetNuke 5.3.

What is a Hackathon?

A Hackathon is a developer event that occurs over a short period of time.  Hackathons are informal events aimed at teaching developers some new technology which the developers then use in the development of a new project.  Because of the immersive nature of the events, developers are able to get a good jumpstart on using some new technology or development technique.  These events are designed to encourage participation by people who may not be familiar with a particular technology or concept.