Summary

Creating Containers

This section looks at the procedures associated with creating a container for your skin. Containers are basically skin definitions applied at the container level. The process for creating a container is similar to the process for creating a skin, with the only real difference being the attributes and skin objects available for a container.

One requirement of creating a container is that you must include an Actions control so you will be able to administer the module's functions. The Actions control is a mechanism that allows binding of the module functionality to the portal framework. It is essentially the user control the module requires to do its intended work. Each module can define its own additional actions, but generally you will have standard functions to add and edit the module's content as well as the portal-level functions to move the module between panes and pages and edit the module settings including permissions, title, and so on. These are the minimum actions required, but the module developer can also create additional actions to perform unique functions of the module in question. The default actions menu uses the SolPartActions control, which functions as a pop-up menu when you hover over the edit icon located in the module container. This menu works best on the latest browsers and performs most reliably when using Internet Explorer 6+. There is a downlevel version of the control that will automatically be rendered to produce a drop-down box when you connect with one of the older browsers that doesn't support the advanced browser capabilities.

As mentioned throughout this chapter, you will want your skins and containers to complement each other and produce a consistent look throughout your design. So it's best (and probably a little easier) to design the skin and containers in conjunction with one another, even though they are really separate entities. Now that you have the basics, you can look at an example for a container manifest file. You will recall the manifest is where you define the attributes you want for the associated skin objects. To simplify this operation and provide a higher degree of granularity, a concept known as Pane Level skinning is also available. Pane Level skinning can be configured only at design time when the skin designer constructs the skin. It involves the use of some custom attributes, which can be included in the markup for the pane. The ContainerType, ContainerName, and ContainerSrc attributes can be used to identify a specific container to be used with all modules injected into the pane. For this to work correctly, the container must exist in the location specified; otherwise, the default container is displayed. Listing 16-6 demonstrates a basic example of this concept.

Listing 16-6: Pane Level Skinning

 <Objects>      <Object>          <Token>[CONTENTPANE:1]</Token>          <Settings>               <Setting>                   <Name>ID</Name>                   <Value>LeftPane</Value>               </Setting>               <Setting>                   <Name>ContainerType</Name>                   <Value>G</Value>               </Setting>               <Setting>                   <Name>ContainerName</Name>                   <Value>DNN</Value>               </Setting>               <Setting>                   <Name>ContainrSrc</Name>                   <Value>standard.ascx</Value>               </Setting>          </Settings>      </Object> </Objects> 

This example shows that it is possible to define standard containers for each section of the skin's design. You can also set the default container at the portal level, which will apply to any new modules created in the portal. The preceding example makes the process of adding content less time-intensive because you won't need to set the container after the module is added to the page.

As you can see, the container functionality in DotNetNuke is just as powerful as the skinning process, and the distinct look of your design can be accomplished using this technology. Table 16-3 showcases the skin objects available to you when you are developing your containers.

Table 16-3: DotNetNuke Core Container Skin Objects

Token	Control	Description
[ACTIONBUTTON]	<dnn:ActionButton runat="server" >	Generic button control used for various actions involving a module.
[SOLPARTACTIONS]	< dnn:SolPartActions runat="server" >	Pop-up module actions menu (formerly [ACTIONS]).
[DROPDOWNACTIONS]	< dnn:DropDownActions runat="server" >	Simple drop-down combo box for module actions.
[LINKACTIONS]	< dnn:LinkActions runat= " server" >	Links list of module actions.
[ICON]	< dnn:Icon runat="server" >	Displays the icon related to the module.
[TITLE]	< dnn:Title runat="server" >	Displays the title of the module.
[VISIBILITY]	< dnn:Visibility run at="server" >	Displays an icon representing the minimized or maximized state of a module.
[CONTENTPANE]	<div runat="server" >	Injects a placeholder for module content.

Notice that you have some of the same functions available to your skinning functions, but you have also added a few objects that do not make sense from a page level but become important on a module level. These are powerful objects that can increase the use of your modules and containers, so you should take some time to experiment with the various uses of these skin objects. Table 16-4 covers the associated attributes you can use in conjunction with the skin objects for containers.

Table 16-4: DotNetNuke Core Container Skin Object Attributes

Token	Attribute	Default	Description
[ACTIONBUTTON]	CommandName		Maps to ModuleActionType in DotNetNuke.Entities.Modules.Actions:[ AddContent| EditContent| ContentOptions| Syndicate-Module| ImportModule| Export-Module| OnlineHelp| Module-Help| HelpText| PrintModule| ModuleSettings| DeleteModule| ClearCache| MoveTop| MoveUp| MoveDown| MoveBottom| MovePane| MoveRoot].
	CssClass	CommandButton	CSS class for the button.
	DisplayLink	True	Displays the localized text for the command (value: True, False).
	DisplayIcon	False	Displays the icon for the command (value: True, False).
	IconFile		File to use for command icon if you're not using the built-in command icon (for example, myicon.gif).
[SOLPARTACTIONS]			The module action Solpart dynamic menu that is exposed to logged-in users who have permission to perform various module actions.
[DROPDOWNACTIONS]			The module action drop-down list that's exposed to logged-in users who have permission to perform various module actions.
[LINKACTIONS]			The module actions listed as links that are exposed to logged-in users who have permission to perform various module actions.
[ICON]	BorderWidth	0	Border width around the module icon (if applicable).
[TITLE]	CssClass	Head	Style name of title.
[VISIBILITY]	BorderWidth	0	Border width around the max/min icon.
	MinIcon	min.gif	Custom min icon file located in the skin file.
	MaxIcon	max.gif	Custom max icon file located in the skin file.
[CONTENTPANE]	ID	ContentPane	Content pane key identifier to be displayed in the user interface and stored in the database.

Now that the objects and attributes are defined, here's an example container for the DotNetNuke project. Listing 16-7 displays the DNN-Blue container from the default install. This container uses the attributes discussed previously.

Listing 16-7: Example Container

 <TABLE  cellSpacing="0" cellPadding="5"  align="center" border="0">   <TR>     <TD >       <TABLE width="100%" border="0" cellpadding="0" cellspacing="0">         <TR>           <TD valign="middle" nowrap><dnn:ACTIONS runat="server"   /></TD>           <TD valign="middle" nowrap><dnn:ICON runat="server"  /></TD>           <TD valign=" middle" width="100%" nowrap>&nbsp;<dnn:TITLE  runat="server"  /></TD>           <TD valign="middle" width="20" nowrap><dnn:VISIBILITY  runat="server"  /></TD>          </TR>        </TABLE>      </TD>    </TR>    <TR>      <TD  runat="server" align="center"></TD>    </TR>    <TR>      <TD>        <HR >          <TABLE width="100%" border="0" cellpadding="0" cellspacing="0">            <TR>              <TD align="left" valign="middle" nowrap><dnn:ACTIONBUTTON1  runat="server"  CommandName="AddContent.Action"  DisplayIcon="True" DisplayLink="True" /></TD>             <TD align="right" valign="middle" nowrap><dnn:ACTIONBUTTON2  runat="server"  CommandName="SyndicateModule.Action"  DisplayIcon="True" DisplayLink="False" />&nbsp;<dnn:ACTIONBUTTON3  runat="server"  CommandName="PrintModule.Action"  DisplayIcon="True" DisplayLink="False" />&nbsp;<dnn:ACTIONBUTTON4  runat="server"  CommandName="ModuleSettings.Action"  DisplayIcon="True" DisplayLink="False" /></TD>           </TR>         </TABLE>     </TD>   </TR> </TABLE> <BR> 

The example in Listing 16-7 is a simple container that helps the display and feel of a portal with a blue-colored theme. You may notice that an ASCX container option is included here. If you were going to use this container, you'd need to add the Register directive for each of the controls added.

When creating a container, the designer should keep in mind that the container will hold the modules' content and also expose module actions through use of the module action menu. This is important to remember because the majority of DotNetNuke modules need this functionality, which is exposed only by the container. With regard to a container holding the content of a module, the designer should keep flexibility in mind because not all modules are going to expose content and functionality that can be confined within the same width and height constraints. Some designers may refer to this as an elastic layout.