Typically, DotNetNuke modules have multiple interfaces seen by end users. These interfaces can be something as simple as a control designated for creating new or editing existing content for a module. For example, the core Text/HTML module has an edit interface that is used to add or modify the content displayed when site visitors see the Text/HTML module on a DotNetNuke page.

When modules have multiple user interfaces, there needs to be a way for users to reach the other interfaces beyond just simply viewing the page containing the module. Often, the way this is accomplished is by using module actions. Using the Text/HTML module example, users can reach the edit interface by selecting "Edit Text" from the module actions menu if the user is logged into the DotNetNuke website and they have edit permissions on the module. When this option is available and the end user selects the "Edit Text" module action, they are navigated to a screen where they see the edit interface. If you have ever used the Text/HTML module, you have probably noticed that when this happens no other modules appear on the page when you are directed to the edit view.

The reason users don't see additional modules in the edit text screen is because DotNetNuke checks the URL for a parameter "ctl". If DotNetNuke sees the parameter "ctl" in the URL, it will do two things: Load only the module that has it's module ID in the URL (represented by mid in the URL), and the other is loading the module in the assigned Admin Skin set in Site Settings under the Appearance section. While this is fine for the Text/HTML module, this can cause confusion in some modules where the page assigned skin may be drastically different from the assigned Admin Skin for the site.

While the way this functions is fine in most use cases such as the Text/HTML module, in some cases this may not go over so well. For example, let's say you have a module like a Forum that has a search interface that is not initially displayed on your page. In a situation like this, if the site has a custom skin assigned that is completely different from the assigned Admin Skin it will look very odd when users click search and are navigated to a view which is using a completely different skin.

To avoid this, module developers need to create a way to dynamically load the control themselves instead of relying on the DotNetNuke framework. To accomplish this, developers should set the initial "View" control to a dispatch page that determines which interface to load based on what parameters are in the URL. At AppTheory, we often use the parameter "mctl" and then have our 'dispatch' page check for this parameter in the URL. If the parameter doesn't exist, we simply dynamically load the control that would have been set as the initial view control for the module. If the parameter does exist, we check the value for "mctl" and load whatever interface we have that corresponds to the mctl parameter in the URL. A very important thing to keep in mind: if the developers is dynamically loading the control instead of DotNetNuke, you must create your own security methods for checking who can/cannot see the control. (This is because the framework sees this as the "View" type therefore anyone viewing the control can view any of the ones dynamically loaded by it at runtime.) You can extend the core permissions grid to accomplish this, but it will not be covered in this blog post.

One thing to note about this method, doing this means you do not have to include the interfaces you will be loading this way in the .dnn manifest file because you will not be depending on the DotNetNuke framework to inject the proper module control. The only files that MUST be declared in the manifest file are those you want loaded using the 'ctl' parameters in the URL.