Modules

Portal Organizational Elements

There are four main organizational elements for portals: parent/child portals, pages, panes, and containers. You'll examine all of them in the following sections.

Parent/Child Portals

A child portal has its own discreet membership, modules, and so on — essentially its own portal entirely — within the same domain as a parent. DotNetNuke creates a physical directory and file that enable IIS to recognize the portal's existence. Child portals make sense within a single domain, leveraged to intranets, SSO, and so forth.

A parent portal has no subdirectory, although it can remain within a domain by using cnames (sales.Domain.com, for example).

Let's look at the differences in the format of the URL between the two types of portals. A parent portal's URL takes the format of http://www.YourDomain.com, whereas a child portal takes the format of http://www.YourDomain.com/YourChildPortal. The application installation may contain any combination of parent or child portals. The only real difference between how you set up the various types of portals is how you define the portal. Figure 3-1 shows the options available in the Portal Setup module.

Figure 3-1

The module gives you several options when setting up a new portal. Notice the radio buttons for selecting a parent or child portal. Selecting the child portal requires no further configuration outside of the application. To set up a parent portal, you must perform some additional steps. You first need to set up an additional web site in your IIS Manager with host headers for your domain name, and then create a DNS record to point to the IP address of your web server. Information on how to perform these tasks is outside of the scope of this book, so please refer to your IIS and DNS help files for the steps. You can find specific details on how to use each of the functions for setting up a new portal in Chapter 5, which covers the host functions of DotNetNuke.

Pages

Pages are a relatively new term in DotNetNuke. Prior to version 3.x, these were called tabs. This change was made to allow for a more user-friendly experience for the novice who may not be a programmer by trade. You can think of a page in the same way you think of a static HTML page. The difference is that the application loads the content based on the parameters passed to it at runtime.

Note 

A page can also be only a navigational component. For example, when you specify the Link type in a Pages advanced setting, the Page element becomes either a link to an external element or simply a pointer to a real page within the site.

In reality, there is only one primary page in the application that displays all the content to your users. Exactly how this works is explained in detail in Chapters 7 and 8. Figure 3-2 shows the options for administering your portal pages.

Figure 3-2

On the left is a Page Functions menu. The buttons in this menu provide quick access to often-used page-management functions. They're described in Table 3-1.

Table 3-1: Page Functions

Function	Description
Add	Enables you to add a new page to the portal. After clicking this button, you are presented with the Page Management control, where you can define properties such as the page's name, title, keywords, permissions, and so on.
Settings	Enables you to modify an existing page.
Delete	Enables you to remove the current page from your portal.
Copy	By default, enables you to copy the modules located on the current page. You also have the option of duplicating the content in the modules of the current page, which can be a real time-saver when setting up your portal.
Preview	Enables you to view your page in the same manner your users will view it. This helps you ensure that your users see your content as you intended. This function also produces more questions than any other function for novices with DotNetNuke. If you are administering your portal and suddenly notice you can no longer edit the individual items of your modules, make sure that this Preview mode is turned off because it is likely your problem.

Clearly the name adequately describes each button's function. DotNetNuke attempts to follow this same structure throughout the application. Figure 3-3 illustrates the options available in the Page Management page, which you use to add new pages to your portal.

Figure 3-3

As you will see in later chapters, DotNetNuke uses an object-oriented approach in all functions, where feasible. You will see many of the same options available throughout the administration screens. The application uses the same user controls in numerous areas, which accomplishes two main functions: it allows a consistent look and feel to the application, and it simplifies the amount of code required to perform these functions.

Notice the question mark images in Figure 3-3. These images expand when you click them, offering some additional descriptions on the type of information the field expects. This reduces the learning curve associated with managing the portal content.

Panes

Panes are the areas of your skin that hold the various content modules you drop on each page. These enable you to organize your content in a manner that makes the best use of your site's real estate. The number and placement of panes is a function of your skin design. For a full discussion on creating skins, see Chapter 16. Panes are populated dynamically at runtime with the modules assigned to them. The types of modules you can use to display your content are discussed in the "Modules" section later in this chapter.

If DNN cannot find a pane — that is, a pane name that matches — it puts the modules in the ContentPane. If a skin is significantly different, the layout changes, but all the functionality is preserved (nothing breaks).

Note 

DotNetNuke ships with several prebuilt skins to help you get started launching your new site.

Containers

Containers enable you to enhance the look of your portal without any design changes to your skin. A container's purpose is to surround the content of a module with some design element, which allows you to bring more attention to the content of the module. You have two options for applying containers to your portal: You can apply a default container to your entire portal and, if desired, set a container for each module. Go ahead and add a module to a page and set up a container for a visual reference.

Now, modify the container of the Links module to change the look of the default page. First, select Settings from the module actions menu, as shown in Figure 3-4.

Figure 3-4

Selecting the Settings tab navigates you to the Module Settings page for the Links module. Notice that the Module Settings page contains many of the same options as the Portal Settings page. (This is an example of maintaining a consistent interface throughout the application through the use of the object-oriented programming used in DotNetNuke.) Scroll down to the Page Settings ðBasic Settings Panel in the Module Settings control. (You may need to expand the panels by clicking the + sign for each panel and selecting a new container for this module.) Currently, this module is using one of the default containers that ship with the application. Select the DNN ð Blue ð Text Header ð White Background container and update your module. You are then taken back to your original page and will immediately see the difference this one change makes. Update all the modules on this page so that you can really see the difference. Although it's much more exciting in color, the black-and-white illustration in Figure 3-5 shows how the entire look of this page changes with only a few mouse clicks.

Figure 3-5

You can see by this example that the use of containers offers a lot of flexibility in "framing" the content of your site. Normally, you will want your containers to match the colors and design of your site, and most skins provide these complements as part of the package. Many commercial and free versions of skins are available for download or purchase. Refer to the DotNetNuke web site for links to a wide variety of skins and containers. Creating skins and containers is covered extensively in Chapter 16.