Last year at OpenForce Connections in Las Vegas, Shaun Walker announced an updated release policy.  The goal in 2010 was to move to a monthly maintenance release schedule along with Quarterly major releases.  Prior to this policy announcement, releases were quite sporadic which made it difficult for our internal planning purposes, and also made it difficult for our users to schedule their own upgrade testing and deployment.  When we first committed to...

Ever since an updated version of Telerik assembly was shipped with DotNetNuke 5.4, people have continued to report that the Telerik assembly is missing from the \bin folder in the upgrade package.  Given the number of reports related to this issue, it is clear that there is a lack of available documentation for how DotNetNuke is packaged.  Some of these problems will be helped by the new wiki project that is being worked on by the Core Reference team.  The wiki will provide a place where we can document application behavior.  Since the wiki is not quite ready to open for public use, I’ll try to document what is going on with respect to Telerik in this post.

During the 5.3 release we originally intended to include an updated version of the Telerik controls. Our goal is to include new Telerik assemblies with each major release.  Since 5.3 was the first major release following the introduction of Telerik controls in 5.2 we had hoped to make the shift.  When we first created the 5.3 package, we found that attempting to upgrade from any of the 5.2.x packages resulted in a yellow screen when you first start the upgrade.  As a result we pushed the Telerik upgrade to 5.4 so we could better study the problem and find an appropriate solution.

Last night we posted another beta of DotNetNuke 5.5 which you can access from the beta release page on DotNetNuke.com.  This is probably your last chance to provide feedback on the 5.5 release as we are nearing completion of the testing cycle.  You can have a direct impact on the quality of the 5.5 release if you act today.

Since the last beta release 2 weeks...

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 Containers

DotNetNuke breaks up our “themes” into two different parts – skins and containers.  In part 1 and 2 of this series, I showed you how to make the page layout portion of a DotNetNuke Skin.  It can be a bit confusing to new users because the term skin is used to describe the entire “theme” and also to describe the page layout portion of a complete skin package.  Containers are a much easier term to understand and will be the focus of this post.

Background

A DotNetNuke website consists of a set of pages on which the user places and configures one or more modules.  In order to integrate the module into your website the framework wraps your module in a DotNetNuke Container.  Containers are designed to coordinate with the corresponding skin as one element in a unified design and are used as a frame around your individual bits of content. Containers provide the ability for designers to seamlessly integrate modules from many different developers into a single cohesive site design.  Since the designer has complete control over the appearance of the container, they can choose to visually frame content or to even have content blend in with the rest of the page elements such that there is no differentiation to a normal end user where one module ends and another module begins.  Containers can also include visual elements which allow the user to interact with the module.  At a minimum, most containers will include the Module Action Menu that administrators and editors use for configuring the module.

Your DotNetNuke site can be configured with a default container which can then be overridden by both individual pages and modules.  Even though a set of containers may be designed for use with a particular skin, you are free to mix and match any container with any skin and to use several different containers on a single page.  This flexibility is one of the great strengths of the DotNetNuke Skinning engine as it allows a small set of skins and containers to provide for many different layouts and designs for a given site.