DotNetNuke Modules – Anatomy of the View

Now that we’ve laid the foundation of DotNetNuke modules, it is time to start looking at the specific modules. While it would be practically impossible to cover every detail and every API feature of a DotNetNuke component, we do want to look closely enough that you know what you are looking at as you are trying to write your code.

Open up Visual Studio and open the code behind for the view module we created. If you are following along, this would be the ViewDMBSample.ascx.cs file.

Starting from the top, you’ll notice that the class has been wrapped in a name space. You’ll want to change “YourCompany” to something unique to your company. If you have a domain, you might decide to use that. I use “dmbcllc” for mine.

The second item you’ll notice is that the class ViewDMBSample inherits from PortalModuleBase and IActionable instead of System.Web.UI.UserControl. PortalModuleBase inherits from System.Web.UI.UserControl, so you haven’t lost anything, DotNetNuke has just inserted some additional functionality between System.Web.UI.UserControl and the code we will be writing. It is PortalModuleBase that gives us access to things like the ModuleId and PortalId properties that we will need to do our module development.

That all makes sense, you say, but what about that IActionable thing?

IActionable tells DotNetNuke that this control implements the ModuleActions property that you will find in the “Optional Interfaces” code region. ModuleActions returns a collection of type ModuleActionCollection and each element in that collection adds an additional action to the module’s action menu.

The property looks like this right after you’ve run the template wizard:

public ModuleActionCollection ModuleActions
        ModuleActionCollection Actions = new ModuleActionCollection();
            ModuleActionType.AddContent, "", "",
            this.EditUrl(), false,
            SecurityAccessLevel.Edit, true, false);
        return Actions;

But by simply adding another Actions.Add() statement, you can add another menu option that will load another ASCX file that has been registered with DotNetNuke. The details on how we would do that, exactly, are the topic of our next lesson.

Finally, we want to take a quick look at the Page_Load() method where we commented out most of the functionality. The one thing that I want to point out today is the catch block at the bottom:

catch (Exception exc) //Module failed to load
    Exceptions.ProcessModuleLoadException(this, exc);

You want all of your catch blocks to look similar. ProcessModuleLoadException() logs the error into the event log so that you can see the error even if you weren’t running the application at the time the error occured. This is a HUGE benefit to tracking down errors that your customers report.


    Other post in DotNetNuke - Module Development

    Related Post

    2 Responses to “DotNetNuke Modules – Anatomy of the View”

    Leave a Reply

    Comment Policy:

    • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
    • Leave me pure spam and I'll delete it.
    • Leave a general comment and I'll remove the link but keep the comment.

    Notify me of followup comments via e-mail