Setting Up Your Web Server

Now that you have your files configured for your DNN installation, you must configure a website, or web application, within your local web server. If you are running Windows XP on the computer that you will be installing DNN on you will be limited to configuring DNN as a virtual directory/application on the machine, or replacing the default website available in XP. In Windows 2000/2003/Vista/2008, you actually have the ability to configure multiple websites in IIS, which means that you can configure DNN in its own website. The difference between a website and a virtual directory/application is pretty simple. A website can be thought of as a domain name or computer name, such as http://www.dotnetnuke.com or http://computername/, whereas a virtual directory generally has the format of http://computername/dotnetnuke/. For the purposes of this book, we will be configuring DNN as a website.

Portals

DNN provides the ability to host multiple websites on one installation, or instance, of the software. These individual websites are known as portals, so your DNN instance can have a single portal, or multiple portals, depending on your configuration. We will talk more about portals later in this chapter, as well as in Chapter 8.

Pages

With any website, you will have pages. These pages are generally files located on the web server and returned by the server to the user’s browser. With a dynamic content management system such as DNN, these pages are not individual files stored on the file system but dynamically generated files that are built with information from the database and returned to the browser. Each page generated within DNN will have its own unique address, or URL (Uniform Resource Locator).

Tabs and Pages

In DNN, the terms ‘‘page’’ and ‘‘tab’’ are interchangeable. We primarily will use ‘‘page,’’ but there will be a few references to ‘‘tabs.’’ Just understand that when we are talking about a tab, we are talking about a page.

URLs

A URL is basically an address that a browser and web server use to locate the information requested by a visiting user. A URL generally consists of a domain name, such as www.wrox.com, followed by a directory structure, and then a page (file) — for example,http://www.wrox.com/WileyCDA/  or

http://www.wrox.com/WileyCDA/Section/Home.id-105001.html.  

In most cases, files of the type .htm and .html are static, as they actually exist as an individual file on the web server. Many dynamic content management systems will build URLs that use what are known as query string parameters, which are name/value pairs that are passed after a filename in a URL. For example, previous versions of DNN would build their URLs as follows: http://www.dotnetnuke.com/default.aspx?tabid=825 ,

where default.aspx is the filename and tabid=825 is the query string parameter. This parameter tells DNN to load page number 825 from the database and return the content for that page to the user. DNN uses query string parameters in a number of ways, more than just for the page ID. In the past, these parameters generally were not thought of as being a good practice. The generally accepted theory was that search engines treated pages that had query string parameters with less weight than pages that appeared to be a static file. It was assumed that search engines would pick up on the fact that a page was being loaded dynamically and treat the content on that page with less respect than they might a static HTML page. Although engineers from Google have debunked this theory, it is still generally recommended to avoid using query string parameters where possible. The recent versions of DNN avoid using query strings in URLs by using what are known as friendly URLs. Friendly URLS can take many forms, but the default in all basic DNN installations will be of the following format. The URL we looked at earlier, http://www.dotnetnuke.com/default.aspx?tabid=825,

would become

http://www.dotnetnuke.com/tabid/825/default.aspx

using the friendly URL formatting. To the search engines and individual users, this looks like a static page that exists on the server, when in fact there is no directory with the path of tabid/825 and a page called default.aspx within that directory. DNN dynamically parses the URL to figure out which page is being loaded and still treats that URL as query-string-based. It is possible to change the formatting of the URLs on your DNN website by plugging in a new friendly URL provider. These providers are developed by individuals or companies usually not directly affiliated with the DNN project..

Skins

There are a number of ways to manipulate and control the layout of the content of your DNN website. The primary layout configuration is handled through the use of a skin. A skin is a file consisting of HTML and other code that provides formatting and styling information for your site. A skin also provides the location(s) available for placing content on a page. These locations are called panes. All skins have at least one pane, called ContentPane. Beyond that, it is up to the skin developer to provide additional panes. Skins generally are constructed with HTML code, although they may also have VB.NET or C# code embedded within them to provide additional functionality. The important thing to realize with skins in DNN is that a website will have a default skin defined, but this setting can be overridden at the page level, meaning that you can control the look and feel of individual pages. The flexibility of DNN and its skinning engine lets you change the look and feel of your website by choosing a new skin through the page settings. Changing skins is a pretty straightforward process that requires only a few mouse clicks to change a few settings. DNN comes with one skin package by default, the MinimalExtropy skin. While there are no other skin

packages currently available on your DNN site, you can use the Extensions page to install skins that you have developed, gathered, or purchased from other sources. Any skin that is installed from the HOST/Extensions page will be available to all portals within an instance of DNN.

Modules

In addition to the layout and styling, the other basic component of a DNN web page is the page’s content. As content is generally key to having a good website, it is an important aspect of any web page. In DNN, content is provided through the use of modules, mini-applications that are one of the key strengths of DNN’s flexibility. Although there are thousands of modules available for DNN, we will focus on the modules available with the basic installation package downloaded from DotNetNuke.com. (Refer to Chapter 1 for a brief description of each module’s functionality.)

To provide content and functionality to a page, a module must be placed on the page in one of the available panes. You can have multiple modules within a pane and multiple panes on a page, so effectively you are not limited in the number of modules you can place on a page, although good web practice would lean toward not weighing a page down with too much content. We will discuss how modules are installed later in this chapter, and then, in Chapter 4, we will cover the basics of using modules within your DNN pages.

Containers

A container is to a module what a skin is to a page. Containers are HTML snippets that wrap around modules within a pane and define any borders, a title for the module, and other design elements for modules on a page. At the portal level, you can define a default container for all modules on your website, which can be overridden at the page level, defining a default for the page and then again at the individual module level.

Containers also have an HTML section, called ContentPane; the difference between a container and a skin, however, is that a container can have only one of these panes, not multiple ones. The ContentPane within a container provides the location for the content and functionality of a module to be displayed. Although containers typically provide some other basic functionality to all users, such as links to syndication data (RSS), to a printer-friendly view, and to the actions a module can perform, the most important functionality is reserved for users who have edit rights to the module.

You can administer modules by selecting a menu or buttons within the container that link to the actions available for that module. Although a number of actions are common to all modules, some actions are specific to the individual module. Chapter 4 describes the common module actions in more detail and then subsequent chapters cover actions available to specific modules, as we walk through various scenario-based websites.

本文转自xwdreamer博客园博客，原文链接：http://www.cnblogs.com/xwdreamer/archive/2009/12/26/2297191.html，如需转载请自行联系原作者