“One of the challenges in creating new modules (for beginners) is the amount of complexity required to "register/create" a new module.”

The above statement was taken from an enhancement description in DotNetNuke’s feature and bug tracking system, Gemini. The issue outlines a plan for addressing that concern by adding new features to the existing functionality in DotNetNuke 5.2. This new feature will be used most by developers that are new to the DotNetNuke world. This blog post will give you a first look at this new feature and explain its usage.

I’m thinking this enhancement will be used most by developers that are new to the DotNetNuke world. On the surface, it seems as though it is only a new way for people to get started with creating DotNetNuke modules. However, it may also benefit more experienced DNN developers by providing them a quick and easy way to get their functionality into a DNN site. These features will remove nearly all the friction involved in prototyping a simple module.

Pre-DotNetNuke 5.2

Within the current version of DNN, developers have a couple of options for registering modules on the website through the user interface. We’ll exclude the most common method, where one selects an installation (.zip) package to trigger the registration process.

Create New Module

From the Host -> Module Definitions page an option to “Create New Module” is available. This method allows for the creation of the module definition. Essentially, it walks the developer through the process of filling out each of the sections of the module’s registration without actually adding any content to it (i.e. registering .ascx user controls).

Import Module Definition

There are two options for importing a module, also available from the Host -> Module Definitions page; importing a control and importing a manifest file.

The first option allows one to select a user control (.ascx file) that has been placed in your DesktopModules folder. The DesktopModules folder is the location within the root of your website where all of the physical files for a module will typically live. So if you place the user control in “/DesktopModules/IanRobinson/SuperModule/SuperModuleControl.ascx” – you’ll see it show up in the “Import Control” drop down. The only pre-requisite for a control here is that it needs to inherit from the DotNetNuke.Entities.Modules.PortalModuleBase class.

After you import the control a bare-bones registration is created based on the name of the control, and that control is made the default “view” control. So effectively you can now go and drop the single-module control that was just created on a page and start using it.

The second option allows you to import a module manifest file (with the .dnn file extension). This is useful when you have more than just a single user control placed in the DesktopModules folder. Typically this is used to “manually” register a packaged module that includes several components above and beyond the default “view” user control.

Enhanced Functionality in DotNetNuke 5.2

In the copy of DotNetNuke 5.2 Beta 4 (build 110) that is available from codeplex.com, some new options appear on the Create New Module page (linked to from the Module Definitions page).

We now have the ability to create a module from scratch, an existing user control, or an existing manifest file.

The latter two, existing user control and existing manifest file, are simply enhanced versions of the functionality we discussed previously, whereas the ability to create a module without an existing user control or manifest file is brand new.

An exciting new feature for all of these options is the ability to automatically create a test page and place a copy of the new module on that page by checking an “Add Test Page” check box. This is a very simple but valuable feature that helps remove extra (obvious) steps from the process of registering your module on the site and testing it.

Now, the whole point of the awkwardly named “Create Module From: New” feature is to allow you to quickly create a module (consisting of a single new user control) without leaving your DotNetNuke website.

Let me break down the elements in the above screenshot:

1. Optionally define an “owner folder,” which allows you to nest your user control two folders deep (e.g. DesktopModules/EngageSoftware/NewModule/MyControl.ascx)
2. Define a folder for the new (yet to be created) control to live in, if you chose an owner folder, this folder will be inside of that one
3. Specify the language you intend to use in your control
4. Specify the file name (important, you need to type “YourControl.ascx” for the control to be created properly)
5. You can then add a name and description for your module
6. Choose whether or not to create a new page (This should probably be defaulted to checked, because you’ll probably always want to…)

Here is what the result looks like:

The page this module was placed on is called “Test My Control Page” and I was taken here automatically after I clicked the “Create Module” button on the previous screenshot.

You may be thinking to yourself “Ok, that’s great, but now what – do I open notepad or Visual Studio or…?” Brace yourself – but the answer is no, you can now edit the newly created module control right on the page, and for that matter, any module control (Yes, really, even the core controls). The only catch is that your site has to be running locally, so this feature is only for developing and testing from the machine the site is running on when you're logged in as a host user.

If you’re running locally, each module now has a View Source option available.

When clicked, you see (and edit) the contents of the module control:

Notice that it includes the following: which allows you to write your own C# or VB code. From here you could add some functionality/logic into the page itself, and then even go back to the Module Definitions page and create a module package from the newly created module.

So in summary, the new Create New Module feature really will help new developers get acquainted with the module development process, and also aid in the rapid prototyping of modules for more experienced developers. Though, I’m a little worried that the ability to edit the source of any given module’s controls which came along with this feature will be abused and lead to a few too many questions in the DotNetNuke forums, but one can hope. What do you think?