User Content Modules

Module Architecture

This section explains the concepts of a portal, page, module container, and the module itself. A walkthrough of how a page is constructed is also presented.

Portal

As discussed in earlier chapters, a portal can be defined as a web-based application that provides content aggregation from different sources and hosts the presentation layer (modules) of information systems.

Figure 6-1 depicts a portal's basic architecture. DotNetNuke needs to perform a number of steps to process a page request. The following steps execute during the initialization of the page and work to dynamically load modules at runtime. The dynamically created modules are then capable of handling their own life cycle including events such as initialization, load, and render.

Figure 6-1

Step 1: Page Configuration Retrieval

The first step is to retrieve the modules for the requested page. The retrieval step comprises a number of important pieces of information, such as the modules that appear on the page, the section of the page on which they will appear (known as content panes), and, finally, the security roles associated with each module.

Step 2: Security Audit

The second step is to make some decisions about the security information retrieved in the previous step. By examining the current user roles (whether a registered user or anonymous) and the view roles associated with each module, you can form a list of "authorized" modules for the current page.

Step 3: Content Injection

The third (and final) step is to inject the "authorized" modules dynamically into the corresponding content panes of the page. After all of the modules have been loaded, each module is then able to execute its own series of events and render content.

Page

Figure 6-2 depicts the basic portal page components. The page itself represents a complete markup document consisting of a number of content panes, and in each content pane, a number of modules. In addition to the modules, a page consists of navigation areas and site banners. To learn more about how to customize the look of these other areas, see Chapter 16.

Figure 6-2

Each module consists of a title, decorations, and the content produced by the module. The decorations can include buttons, links, and a hover menu that can change the module's state or perform functionality specific to that module.

Module

As mentioned previously, a portal is a web-based application that processes requests and generates dynamic content. Each module produces its own piece of markup (known as a fragment) and together with the skin's markup shows a complete document.

Because each module produces its own markup, it can be viewed as a tiny application within a larger application. Usually, users interact with the content produced by each module by clicking links or submitting forms that are then processed by the portal system and the command passed to the corresponding module.

Module Container

The decorations surrounding a module are known as a module container. Through this container, a user is able to interact with the module and perform actions such as minimizing, maximizing, and more advanced features (if the user has edit privileges on that module).

Figure 6-3 shows the module container of a Links module when a user is logged in with edit access. It includes a number of items, such as the hover menu with a list of administration options (discussed later in this chapter), the title of the module, and the minimize/maximize option.

Figure 6-3