An Easy Way to Test Containers

If you ever tried to create a set with several containers, I'm sure you have seen how time consuming can be, to apply one by one the containers you have created so you can be sure that everything looks and works as it should.
DotNetNuke from the very early versions, give to the skinners the ability to preset the usage of a specific container in a pane. This concept is known as Pane Level skinning. Take a look in the following code:

The containertype, containername and containersrc are the attributes we're talking about. Let's see what they mean.

containertype

With this attribute we tell DNN whether our container is stored under the \Portals\_default\Containers\ directory or under our \Portals\{portal ID}\Containers\ directory. In the first case the containertype needs the value G and in the second the value L.
Just a reminder here that we store our skins and containers under \Portals\_default\, when we want to make them available to all portals that will be created with our DNN installation. Instead, when we put them under \Portals\{portal ID}\, they will be available only to that specific portal (for example \Portals\0\).

containername

This is the name of the folder where our containers reside in, which is also the name of our containers set. For example \Portals\0\MyContainers. There is no default value and we use just the name of the folder, not the full path.

containersrc

This is the file name of the container we want to apply, which is also the container name. For example \Portals\0\MyContainers\MyContainer.ascx. There is no default value and we use just the name of the file, not the full path.
All three attributes are required. If we forget one of them or there is an error with one of their values, the default DNN container will be applied.
This concept intended to give the skinners the power to override the Portal Level container in situations that this is suitable. With Portal Level container we mean the Portal Container the administrator has been selected in the Appearance section in Site Settings. The administrator is still able to override the container has been preset from the skinner, applying a new container as Module Container in Module Settings.

1. Portal Container - set by Administrator
2. Pane Container - set by Skinner
3. Module Container - set by Administrator

The problem with this concept is that the containertype, containername and containersrc are not standards compliant attributes. So if we want our skin code and therefore our site to validate, we cannot use them in production. But I find them extremely useful during the development. Instead of going in Site Settings or Module Settings and apply the containers I want to test again and again, I just change the file name value of the containersrc attribute in my skin code.