Professional DotNetNuke ASP.NET Portals wrox phần 5 doc

Skins

You should recall from earlier in this chapter that the only difference between working with skins from

the Admin menu and working with skins from the Host menu is the target location of the upload, which

determines availability to other Portal Administrators. For additional information on skins and skinning,

see Chapters 4 and 13, respectively.

Summary

In this chapter you learned just about everything there is to know about administering a collection of

portals, their environment, and runtime features as the Host (or SuperUser) of a DotNetNuke installa￾tion. Key Host functions that you should understand include

❑ Host Settings

❑ Portals

❑ Module Definitions

❑ File Managers

❑ Vendors

❑ SQL

❑ Schedule

❑ Languages

❑ Search Admin

❑ Lists

❑ SuperUsers Accounts

❑ Skins

You should have some understanding of which Portal Administrator–level functions contain Host con￾figurable settings. These Portal Admin functions include

❑ Site Settings

❑ Skins

❑ Log Viewer

You should understand the location and relevance of the Host Root directory (\Portals\_default) versus

the Portal Root directory (\Portals\<portalid>), and know that Host default settings are used to create

individual portals, but that changing them has no effect on existing portals.

Your SuperUser powers should now be fully enabled and you should be prepared to assume leadership

of your very own DotNetNuke “Justice League” (cape and super hero sidekick not included).

150

Chapter 5

09_595636 ch05.qxd 5/10/05 9:57 PM Page 150

Modules

Now that you are familiar with the Host and Administration capabilities available within

DotNetNuke, this chapter looks at a concept familiar to most portals — modules.

A module is a pluggable user interface component that processes requests and generates dynamic

content. This definition is similar to that of an ASP.NET page, with the exception that a module can

only appear on an ASP.NET page, and that page can contain any number of module “instances.”

Modules are also defined by another important characteristic known as its type. The module type

governs what functionality it provides. DotNetNuke provides a number of modules out of the

box; these modules range from FAQs and Announcements to Documents. You can even author

your own modules that provide alternate functionality.

By the end of the chapter, you should have a good understanding of the architecture surrounding

modules and how they relate to the DotNetNuke Portal System. This chapter also discusses the

practical aspects regarding modules such as management and installation, and provides an intro￾duction to each of the modules included within DotNetNuke.

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 informa￾tion systems.

10_595636 ch06.qxd 5/10/05 10:01 PM Page 151

Figure 6-1 depicts a portal’s basic architecture. To help explain the diagram, DotNetNuke needs to per￾form a number of steps in order to process a page request. The following steps execute during the initial￾ization of the page. This event occurs at initialization so that modules can handle their own life cycle and

process events such as initialization, load, and render.

Figure 6-1

First Step

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.

Second Step

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 associ￾ated with each module, a list of “authorized” modules is formed for the current page.

Third Step

The third (and final) step is to dynamically inject the “authorized” modules into the corresponding con￾tent panes of the page. Once each of the modules has been loaded, each module is then able to execute

its own series of events and render content.

HTTP

HTML

Portal Engine

Portal Skin

Content Pane

Modules

Content Pane

Modules

Conent Pane

Modules

152

Chapter 6

10_595636 ch06.qxd 5/10/05 10:01 PM Page 152

Page

Figure 6-2 depicts the basic portal page components. The page itself represents a complete markup docu￾ment consisting of a number of “content panes,” and in each content pane a number of modules. In

addition to the modules, a page also consists of navigation areas and site banners. To learn more about

how to customize the look of these other areas, see Chapter 13.

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 functional￾ity 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.

153

Modules

10_595636 ch06.qxd 5/10/05 10:01 PM Page 153