irst let me start by saying I have good news and bad news. The good news is that the eagerly-awaited DNN 2.0 officially shipped at the VS-Live! Conference on March 23, 2004. Actually, that’s not good news, that’s great news. The bad news? There aren’t enough hours in the day to work on all the Web sites I want to create with DNN 2.0!

DotNetNuke 2.0 is the latest version of the increasingly popular, open-source, content management portal. At the time of this writing, the current version of DNN is 2.0.4. It was originally released as an open source project on Dec 24, 2002. You can download the latest DotNetNuke code from the DotNetNuke Web site. In the past fifteen months it has grown to over 50,000 lines of managed code. One thing is for sure, you won’t be alone using it! The DotNetNuke support forum is one of the most active and dynamic forums on the www.asp.net Web site. There are currently over 45,000 registered users on the official DotNetNuke Web site and membership continues to grow at an exponential rate.

For those of you unfamiliar with DNN, it provides an off-the-shelf, turn-key, Web portal application containing the key features and tools required to operate and maintain a dynamic and 100% interactive data-driven Web site. DNN provides features that make everyone happy, from the Web site administrator, to the content manager, to the Web site developer. Web site administrators get new features and tools for controlling user membership, security role management, banner advertising, affiliate relationship management, promotion and search engine optimization, and Web hosting. Content managers receive features and tools for content authoring and Web site management. For the Web site developer, DNN is highly extensible, has improved error handling capabilities, and allows them to develop custom modules built in your .NET language of choice. You can upload custom modules, in the form of a private assembly to the server where they are installed directly into the runtime portal environment and ready for use by the Web site administrator and/or content manager. I’ve included a complete step-by-step tutorial for developing custom modules at the end of this article.

Upgrading from DNN 1.0

Before you even think about upgrading, I strongly advise you to back up your database and Web site folders in case you run into issues with your site. The process of upgrading from DNN 1.0 is fairly straightforward. You simply copy the DNN 2.0 files over your DNN 1.0 files and compile. The upgrade process should work and your database will be automatically upgraded. Custom modules written for DNN 1.0 should work but they may not depending on how they were written.

Performing a Clean DNN 2.0 Install.
The steps to performing a clean install of DNN 2.0 are nearly identical to the steps to install a prior version (See March/April 2004 issue of CoDe Magazine for complete step-by-step instructions for installing DNN 1.0.10d). The Readme.txt file in the Documentation directory also contains the steps to perform a clean install.

DNN 2.0 New Features
The DNN 2.0 team completely re-wrote the product and they added a number of new features and enhancements. I have broken them down into four categories: administration changes, skin technology, data access methodology, and custom module (private assembly) development. In this article I will touch on some of the administration changes and I’ll explain what skins are and why you will want to use them. I’ll spend time exploring the new data access methodology and I’ll finish the article by explaining how to develop custom modules in DNN 2.0.

Administration Changes
DNN 2.0 features changes and enhancements revolve around the day-to-day administration of a site and it has some noticeable user interface changes.

Login Page Changes
The login page now displays on its own tab when a user attempts to login to a site. DNN 2.0 adds the login component as a standard module so you can customize the login experience for your site. DNN 2.0 includes a User Account module as a standard module. (See Figure 1 for a list of all the standard modules.)

Figure 1. The Default Page: This default page displays when you create a new site.

?

Figure 2. Available Modules: The figure shows the default page containing a list of available modules.

Administrative Design Surface Changes
For an administrator or someone with group editing rights to a tab, DNN 2.0 made a number of changes to the design surface. Some of the changes support new features while others have been implemented to increase productivity.

	?
Figure 3. Module Context Menus: Modules now support a context menu which displays when the mouse is moved over the module edit pencil.

If you used DNN 1.0, you’ll notice that DNN 2.0 repositions the tab maintenance section to the top of the design surface. Minor changes to tab maintenance section include grouping the Tab add and edit options together, the option to specify which pane (left, content, or right) a new module is added to, the alignment of the new module within the pane, and the ability to toggle the display of page content during a design session (see Figure 2).

Module Context Menus
Content menus now appear when you move the mouse over the pencil next to the module title. The module context menu provides access to a variety of capabilities including positioning of the module, editing the module settings, and deleting the module (see Figure 3). Being able to delete a module without having to edit the module settings is definitely a welcome addition.

Recycle Bin
Are you nervous about being able to delete a module or tab so easily? Not to worry! The Admin menu lets you access the new Recycle Bin tab. The Recycle Bin provides the ability to restore previously deleted tabs or modules, another very welcome addition (see Figure 4).

File Upload Dialog
The Admin and Host File Upload dialogs have been expanded to include the storage location of the file being uploaded. The Host File Upload Dialog also provides the ability to specify the type of content being uploaded (see Figure 5).

Exception Viewer
The Exception Viewer displays any errors that have occurred during the execution of the site.

Figure 4. The Recycle Bin:: The Recycle Bin provides lets you restore previously deleted modules and tabs.

?

Figure 5. The Host Upload Dialog: The Host Upload dialog box includes the file location and content type being uploaded.

Skins
Support for skins is one of the most-anticipated new features in DNN 2.0. So what is a skin? An official sounding definition for skins goes something like this: Skinning is a software architecture that provides a technique to separate application logic and content from its presentation. In clearer terms, it is a design that splits the three segments of an application into distinct pieces. The first piece, the application logic, determines how the site works. For example, this is what happens when a user clicks a specific button. The second piece, the site content, determines the information the site displays. This is the text displayed in a text box for example. The third piece, the presentation, determines how the site looks. For example, you might want to display a logo in the upper left corner.

The separation of the three segments makes it easy to quickly change the look and feel of the site. Changing the look and feel of a site is as simple as uploading and applying a new skin.

	?
Figure 6. Admin Site Settings: The Admin Site Settings dialog box lets you choose which skin to apply to a site.

I have found an analogy to explain skins that helps when I teach a DNN 2.0 training class. Imagine a person as a Web site. The actions they know how to perform, jumping up and down for example, represents the application logic. The things they say, reciting the Gettysburg address for example, represents the site content. The clothes they wear, a formal gown for example, represents the presentation. A quick change of clothes into blue jeans, a t-shirt and a baseball cap would present a very different look for the person but would have zero impact on them reciting the Gettysburg address or knowing how to jump up and down. Skins are all about how a site looks.

DNN 2.0 provides a free-form skinning solution that provides full control over the user interface, and DNN 2.0 supports skinning at the host, portal, and tab levels. You can also skin your module containers. What all this boils down to is that DNN 2.0 provides you with the ability to apply different skins quickly and easily, therefore giving you the ability to mildly or radically change the look and feel of a site with just a few clicks of the mouse. Changing the look and feel of a site is as simple as uploading the new skin and selecting the skin to apply on the Site Settings tab (see Figure 6).

You can find free DNN 2.0 skins available from a number of places on the Web. I downloaded a couple of skins from www.dnnskins.com. Installation is as simple as uploading a zip file from the Host File Manager. DNN automatically unzips the file during the installation process.

I downloaded the ClearCell…Multiskins skin and then uploaded it to my site. I then selected Site Settings from the Admin menu, I selected ClearCell – DarkBlue, and clicked Update. The results (see Figure 7) are pretty amazing wouldn’t you say? I also downloaded the Subzero Solutions – Reach4It skin, installed in on my site, and specified it as the skin I wanted to use (see Figure 8).

Figure 7. Applying a Skin: The figure shows the DNN 2.0 default page with the ClearCell – DarkBlue skin applied.

?

Figure 8. A Different Skin: Here’s the DNN 2.0 default page with the SubZero Solutions – Reach4It skin applied.

As you can see, just likes snakes and lizards can shed their skin, so can your Web site, revealing a totally new look and feel. Additional information on DNN’s implementation of skins is available in the DotNetNuke Skinning Whitepaper found on the official DotNetNuke Web site. Stay tuned to CoDe Magazine for one of my next articles detailing the steps involved in creating your own skins.

Data Access
While the new skin features might be the most important new feature for site administrators and site designers, to developers responsible for coding custom modules, one of the most significant issues with DNN 2.0 is the new data access methodology. The DNN core team has implemented the Whidbey (ASP.NET 2.0) Provider model for data access. Adopting this methodology enables DNN to integrate with any data store. DNN 2.0 ships with a Microsoft SQL Server/MSDE data provider and a Microsoft Access data provider.

DNN 2.0 includes significant revisions to the web.config file. The most obvious of these changes is the addition of the Providers collection to support additional databases (see Listing 1).

The data model in DNN 2.0 takes an n-tiered or layered approach to working with data. If upgrading to DNN 2.0 is going to be your initial introduction to the world of layered data access, be prepared to spend some time absorbing and learning. Your maiden voyage into the uncharted waters of a multi-tiered or layered approach to working with data can be as unsettling as being on a ship in rough. The good news is that it does not have to be that upsetting.

There are four fundamental layers in a typical multi-tiered application: the Presentation layer, the Business Logic layer, the Data Access layer, and the Data Store layer. If you have ever taken a standardized test such as the S.A.T. exam, for example, then you have a perfect frame of reference for understanding how a layered approach to application development works. I will explain each layer and break down the layers in the standardized test taking process to help you associate application layers with your real world experience. Later in the article I will demonstrate how to implement the layers in .NET code.

I will start with the layer closest to the user, the Presentation layer, and work my way back toward the database.

The Presentation Layer
The Presentation layer displays information to the user and provides a mechanism for them to enter or update information. A Windows Form implements this layer in a traditional Windows application and a Web Form (ASP.NET) implements this layer in a Web-based application. I often refer to this layer as the “make the data look pretty” layer. Limited data validation occurs at this layer.

In the example of a standardized exam, the exam itself represents the Presentation layer, though recalling my experiences with standardized exams; the results were rarely “pretty.” Data is collected when an individual taking the exam records their answers on the separate exam answer form. That seems simple enough. No real rocket science here.

The Business Logic Layer
The Business Logic layer (BLL) acts as a conduit between the Presentation layer and the Data Access layer. It is responsible for validating the data passed to it by the Presentation layer before it sends the data along to the Data Access layer. The BLL also retrieves data from the Data Access layer and passes it to the Presentation layer. Typically, a developer creates a Custom Business Object (CBO) (CBO is DNN’s name for a Business Logic layer object) for each table in the database. For example, the CustomerBusinessObject works with data from the Customer table.

The CustomerBusinessObject would handle data validation chores such as ensuring that the customer’s first name and last name are not blank. The code in a CBO is highly customized to fit the requirements of the table it is representing.

Back to the standardized exam example. The exam administrator sitting in front of the classroom who monitors the students during the exam represents the Business Logic layer. A student turning in their completed exam answer form is an example of the Presentation layer passing data to the Business Logic layer. Validation steps the exam administrator might take include verifying the exam was completed in the allotted time, that the student’s name is on the exam, and that the student used a #2 pencil. Did you notice that I didn’t mention anything about scoring the exam or determining if any or all of the questions had been answered? In this case, scoring is not the responsibility of the exam administrator. Once the exam has passed the validation rules implemented by the exam administrator, the test is sent to a testing company for scoring.

Does the exam administrator care what type of database contains the exam results or how the exam results get recorded? No. That is not their responsibility. Handing out the answer forms, applying a few validation rules to exams handed in, and sending the exam answer form to be scored is the entirety of their job.

The Data Access Layer
The Data Access layer (DAL) accepts the pre-validated data coming from the Business Logic layer and calls the correct data updating capability on the Data Store layer. DAL objects are designed and coded for a particular data store to take advantage of specific capabilities and features of the data store including performance and security.

In my standardized exam example, the testing company who receives the pre-validated exam answer form from the exam administrator represents the Data Access layer. Getting the results entered into their system and scoring the exam is their responsibility.

The Data Store Layer
The Data Store layer (DSL) represents the data storage entity itself. For this article, Microsoft SQL Server 2000 is the DSL.

In the standardized test example, the DSL is represented by the database (tables, stored procedures, and so on) that the company stores the exam scores in. Using stored procedures to access and update data is an accepted “best practice” and DNN uses stored procedures exclusively to work with data.

Layered Architecture Advantages
Flexibility is one of the primary advantages of a layered architecture. In the standardized exam example, does it really matter who the exam administrator is? No, so long as they can carry out the duties and responsibilities expected of an exam administrator. Does the exam administrator know what database the standardized exam company uses? No, they do not need to know. Does it really matter what database the exam company uses to store test results? No, as long as they can score the exams and distribute the results to exam takers. Are all of the layers independent of each other? No, they aren’t. Keep in mind that the Data Access layer is coded to work with a specific Data Store layer. If someone decides to swap out the Data Store layer (switch from Oracle to SQL Server for example) someone might have to recode the Data Access layer to take advantage of SQL Server features and capabilities. Would swapping the database have any impact on the exam administrator or change the rules they implement? No. Would the change affect the student taking the exam? No.

A clear and manageable division of human labor is another advantage of a layered architecture. Because you can develop each layer independently of the others, individual team members can handle specific tasks. A graphic artistic can collaborate with a Web designer on the visual aspects of the application (Presentation layer) while developers work on the custom business objects (Business Logic layer). Meanwhile, another team of developers can collaborate with the DBA on the data access objects (Data Access layer). Lastly, a DBA can implement the table schemas and code the stored procedures in the database.

Layered Architecture Disadvantages
The layered approached to accessing data obviously has advantages but it also has disadvantages. The most significant is the level of complexity and potential confusion that comes with having several layers. Because each table has its own Data Access layer object and Custom Business Object, the number of classes can grow very quickly.

Extending DNN with Custom Modules
DNN 2.0’s redesign in the custom module architecture is another significant update. In this section I will walk you through all the steps necessary to construct and deploy your own custom modules. First I’ll show you how to create a SQL Server table and its associated stored procedures (Data Store layer). I’ll show you how to continue to build the Data Access layer by constructing a Business Logic layer object to retrieve and validate entered data. Next, you’ll see how to build the presentation layer and edit the data being served up by the Business Logic layer object. Finally, I will show you how to package all the components of the custom module into a single zip file and upload the zip file for testing.

Before I begin let me list some prerequisites. I will use Microsoft SQL Server 2000 so you will need access to SQL Server to follow along. The DNN 2.0 data access provider model allows you to work with other databases, such as Microsoft Access, but I’m not using Microsoft access as my data repository. You will also need to install the Microsoft Data Access Application Block for .NET. You can find this by searching for Data Access Application Block for .NET on http://msdn.microsoft.com. You will also need a utility that lets you create zip files.

The custom module I’ll show you how to build tracks exam results. The primary user interface will consist of a grid listing the individuals and it will provide a mechanism to add new exam records and edit / delete existing ones. So without delay, I bring you the construction and implementation of a DNN 2.0 custom module.

Step 1: Design and Implement the Data Store Layer
Create a table to store the individual exam records. I created a table called ExamTracker (see Figure 9) as well as the required stored procedures to access the data (see Listing 2).

	?
Figure 9. The ExamTracker Table Structure: The figure shows the structure of the table in the database.

Step 2: Construct the Data Access Layer and Business Logic Layer
Create the Data Access layer (representing the testing company in the earlier example) and associated Business Logic later (representing the testing administrator). In this step I will create a couple of new projects and populate them with classes. The following list walks you through creating these layers.

1. Open the DNN 2.0 project in Visual Studio .NET 2003. I placed my DotNetNuke project files in the C:DotNetNuke20 folder.
2. Right-click on the DotNetNuke solution, select Add and then choose New Project… and add a new class library project named YourCompanyNameHere.ExamTracker and store it in the C:DotNetNuke20DesktopModules folder (see Figure 10). You can see that I created a project named TakeNoteTechnologies.ExamTracker. Launch Windows Explorer to confirm that Visual Studio .NET created a folder under DesktopModules named YourCompanyNameHere.ExamTracker and populated it with the project and associated files.
3. Open the Property Pages dialog box for the new project and make sure the Root Namespace field is empty. Change the Output path to ….in in the Build settings in the Configuration Properties section.
4. Add three folders to the ExamTracker project: Components, Installation, and Providers.
5. Add the following references to the ExamTracker project: DotNetNuke.dll, System.Drawing, and System.Web.
6. Delete the Class1.vb file.
7. Right-click on the Components folder. Select Add and then select Add Class… and name the new class DataProvider.
8. Use Listing 3 as a reference for the DataProvider abstract class. You can copy the Instance method from the DataProvider class located in C:DotNetNuke20ComponentsDataProvider.vb file. Take a moment to look at the data access methods at the bottom. It is no coincidence that the method names correspond to stored procedures of the same name.
9. Right-click on the DotNetNuke solution. Select Add and then select New Project… to add a new class library project named YourCompanyNameHere.ExamTracker.SqlDataProvider and store it in the C:DotNetNuke20DesktopModulesYourCompanyNameHere.ExamTrackerProviders folder (see Figure 11). Switch over to Windows Explorer to confirm that Visual Studio .NET created a folder under DesktopModulesYourCompanyNameHere.ExamTrackerProviders named YourCompanyNameHere.ExamTracker.SqlDataProvider and populated it with the project and associated files.
10. Open the Property Pages dialog box for the YourCompanyNameHere.ExamTracker.SqlDataProvider project and make sure the Root Namespace field is empty. Change the Output path to ….in in the Build settings in the Configuration Properties section.
11. Add the following references to the ExamTracker.SqlDataProvider project, DotNetNuke.dll, ExamTracker, and Microsoft.ApplicationBlocks.Data.
12. Delete the Class1.vb file.
13. Right-click on the SqlDataProvider project, select Add and then select Add Class… and name the new class SqlDataProvider.
14. Use Listing 4 as a reference for the SqlDataProvider concrete class. This class inherits from the DataProvider class and contains methods that override the stub methods in DataProvider.
15. Now it is time to create the Business Logic layer. In the YourCompanyNamehere.ExamTracker project, right-click on the Components folder, select Add and then select Add Class…, and name the new class file ExamTrackerDB.vb.
16. Use Listing 5 as a reference for the ExamTrackerDB Business Logic layer class. There are two classes contained in the ExamTrackDb.vb file. The ExamTrackerInfo class contains properties that exactly match the structure of the ExamTracker table and the ExamTrackerController contains the data access methods.

Figure 10. ExamTracker Project Creation Settings: The figure shows the project creation settings for the ExamTracker project.

?

Figure 11. The SqlDataProvider Project: This project was created to store the SqlDataProvider class.

Build the DotNetNuke solution at this point. Enter information about your module in the AssemblyInfo.vb file for both projects just make sure you are consistent and enter the same information.

Referring to the standardized exam example, the DataProvider and SqlDataProvider classes combined act as the exam company. The ExamTrackerInfo and ExamTrackerController classes combined act as the exam administrator.

Step 3: Construct the Presentation Layer
With the Data Store layer and Data Access layer implementation complete, let’s create the Presentation layer portion of the module. The user interface will consist of two pieces. The initially displayed piece will list all the individual exam results and the second piece will provide a place to edit existing records or add new exam results.

1. Right-click on the ExamTracker project, select Add, select Add New Item…, select Web User Control, and name the new file viewExamTracker.
2. Use Listing 6 as a reference for the viewExamTracker.ascx file. It contains a datagrid that lists the existing records from the ExamTracker table.
3. Use Listing 7 as a reference for the viewExamTracker.ascx.vb file. The first thing of interest is that the viewExamTracker class is inherited from the DotNetNuke.PortalModuleControl.

The DotNetNuke.PortalModuleControl class contains properties and methods required by DNN to inject custom modules into a page. The ModuleID is a significant property. It tracks the ModuleID of the current module. To keep things simple I choose not to use this feature here. You can create modules so that you can use them on multiple tabs. Many of the included modules take advantage of this design feature. For example, you can add the Announcements module on multiple tabs across a site and each Announcement module retains its information independently of the others. I could have implemented this in the ExamTracker module by adding a ModuleID field to the ExamTracker table, modifying the stored procedures to accept and return the ModuleID, and modifying the data access methods to accept a ModuleID parameter. I will leave implementing that to you as an experiment once you get the module working.

The MyBase.Actions.Add call in the Page_Init is the first item of interest in this file.

   ' declare module actions   MyBase.Actions.Add(GetNextActionID,       "Add New Exam", _      "", URL:=EditURL(), _      secure:=SecurityAccessLevel.Edit, _      Visible:=True)

This snippet adds the option to add a new exam when the user selects the menu next to the module title. Add additional lines here for additional options.

The Page_Load method contains the code that retrieves the existing ExamTracker records and binds them to the DataGrid.

1. Next is the piece that will handle editing or adding records. Right-click on the ExamTracker project, select Add, select Add New Item…, select Web User Control, and name the new file editExamTracker.
2. Use Listing 8 as a reference for the editExamTracker.ascx file. It contains controls to display the fields and buttons to update, cancel, or delete the current record.
3. Use Listing 9 as a reference for the editExamTracker.ascx.vb file. It contains all the code necessary to assign values to the controls as well as options for updating, canceling, or deleting the current record.
4. Try to build the project at this point. You should be able to build with no errors.

Step 4: Prepare the Module to Be Installed
Now comes the moment you have been waiting for?testing to see if all this work pays off. Before you can test a module you first need to upload it to a DNN 2.0 site. The process of installing a private assembly, (ExamTracker is a private assembly) is fairly straightforward. But what is a private assembly? A private assembly can only be used by a single application as opposed to a global assembly which you can use across multiple applications.

The DNN 2.0 development team has made installing custom modules (private assemblies) very easy. First, zip up all the files that make up the module. Next, log in as Host and upload the zip file through the File Manager. That’s all there is to it. I’ll walk you through the steps.

	?
Figure 12. ExamTracker Module: Here’s the complete ExamTracker module displayed in the DotNetNuke solution.

1. Right-click on the Installation folder in the YourCompanyNameHere.ExamTracker project, select Add, select Add New Item…, select XML file and name the file ExamTracker.dnn. The .dnn extension indicates that the file is the installation manifest file.
2. Use Listing 10 as a reference for the ExamTracker.dnn file. The file contains all the information required by DNN when the module is installed. Typical information contained in the file are the name of the module, a friendly name to make it easier for the user to understand which module they are using, the names of the user interface files (.ascx), and a list of all the files being uploaded with the module. The Type setting for an .ascx determines whether or not the control is used to display information or act as an editor. In this case Type for the viewExamTracker.ascx file is set to View while the Type for the editExamTracker is set to Edit.

The 01.00.00.SqlDataProvider file contains the T-SQL code to create all the necessary database objects required by the module. I scripted the ExamTracker table and the related stored procedures to create the 01.00.00.SqlDataProvider file. The Uninstall.SqlDataProvider is the SQL code to drop the stored procedures and the ExamTracker.

1. Create the 01.00.00.SqlDataProvider and Uninstall.SqlDataProvider files and store them in the Installation folder.
2. Create an ExamTracker.zip file in the Installation folder and add the files listed in Table 1.

Table 1: Files to Add to ExamTracker.zip

1. You are now ready to install the module. See Figure 12 for a look at the completed project displayed in the Solution Explorer.
2. Run the project to display the DotNetNuke portal (I assume you configured the portal when you installed DNN 2.0).
3. Log in as Host.
4. Select File Manager from the Host menu.
5. Click on the pencil next to the File Manager title and select Upload New File(s).
6. Select Custom Module and click Browse. Locate your ExamTracker.zip file and click Open.
7. Click Add to select the file to be uploaded.
8. Click Upload File(s) to complete the process. You should see a confirmation form telling you the install is complete.

Step 5: Using Your New Module
Now select a tab and drop your new module on it. If all went well you should see the ExamTracker module listed in the module drop down (see Figure 13). You should be able to place the module on a tab (see Figure 14) and see it work (see Figure 15).

Figure 13. Module DropDown: Here’s te Module drop down populated with available modules, including ExamTracker.

?

Figure 14. ExamTracker Displaying a Record: The figure shows a module in use displaying an exam record.

	?
Figure 15. Editing In ExamTracker: Here’s what the ExamTracker module looks like when editing an existing an exam record.

Custom Module Recap
Time and space have limited the depth I could go into regarding developing custom modules. Once you master creating the ExamTracker module I am sure you will want to expand your horizons and check out other modules. One of the best resources to help you understand how to build your own custom modules is to check out how the pre-built ones work. The Survey and UsersOnLine modules that ship with DNN 2.0 are a great place to get started looking at other modules. Table 2 has a number of other resources you can use when creating your own modules.

Table 2: DNN 2.0 Module Creation Resources

I told you I was excited about DNN 2.0 in my last DNN article and now you know why. With DNN 2.0, more and more people are discovering what others already know?DotNetNuke rocks! The DotNetNuke open source community infrastructure is continuing to grow. It is currently over 45,000 members!

I’d like to take this opportunity to again thank Shaun Walker and the DNN Core Team for their hard work and dedication to delivering a fine piece of software. Great job!!