I am porting an existing application to a DotNetNuke module and discovered bizarre behavior. I use ClientID when creating javascript so that the code can identify the HTML elements. Normally that creates a value something like this:

"g_ctl00_ctl01_ctl00_ctl00_txtSearch"

We've all seen this a million times, right? Well, after porting this code to a DotNetNuke module and running it for the first time, the ClientID property is returning this:

"dnn_ctr397_GalleryServerPro.Web.Gallery, TechInfoSystems_ctl00_ctl01_ctl00_ctl00_txtSearch"

Notice the comma and the space. This is causing all kinds of javascript errors. For example, the ASP.NET Login control is now outputting invalid

var dnn_ctr397_GalleryServerPro.Web.Gallery, TechInfoSystems_ctl00_ctl01_ctl01_lv_ctl02_Login1_UserNameRequired = document.all ? document.all["dnn_ctr397_GalleryServerPro.Web.Gallery, TechInfoSystems_ctl00_ctl01_ctl01_lv_ctl02_Login1_UserNameRequired"] : document.getElementById("dnn_ctr397_GalleryServerPro.Web.Gallery, TechInfoSystems_ctl00_ctl01_ctl01_lv_ctl02_Login1_UserNameRequired");

My module has an assembly name of TechInfoSystems.GalleryServerPro.dll, the default namespace is GalleryServerPro.Web, and the user control is in a class named Gallery.cs, so that partially explains where some of that extra text is coming from, but why is it there? And what can I do to ensure that ClientID does not output commas, spaces, or other characters that can cause problems in javascript?

Thanks, Roger

I (sort of) figured it out. I needed to add an ID to the user control that is being added to the DotNetNuke page. This is the main view user control - the one that inherits PortalModuleBase. The user control is contained entirely in a code-behind class (no .ascx), so adding this to the Init event fixed everything:

this.ID = "gsp";

My theory is that the issue happens when these are true:

1. The "view" user control uses only the code-behind file (no .ascx file)

2. The user control does not have an ID specified.

When registering a module without the .ascx, one must specify the class and assembly in the Module Definitions. In my case, it is "GalleryServerPro.Web.Gallery, TechInfoSystems.GalleryServerPro". That looks very close to the text DNN ends up inserting into the clientID string. DNN (or ASP.NET) must be taking that string and using it to build the clientID in the absense of an ID assigned in the user control.

Not sure if this is a DNN bug, but I am happy to figure it out and now can move on...

Roger Martin

Gallery Server Pro

Well, it *is* a user control, it just does not have the .ascx declarative file. In other words, I created a regular class and had it implement PortalModuleBase like this:

public class Gallery : DotNetNuke.Entities.Modules.PortalModuleBase

Then, in the manifest, notice how I reference the Gallery class instead of a .ascx file:

                <component type="Module">
                    <desktopModule>
                        <moduleName>TechInfoSystems.GalleryServerPro</moduleName>
                        <foldername>GalleryServerPro</foldername>
                        <businessControllerClass>GalleryServerPro.Web.GalleryServerProController</businessControllerClass>
                        <supportedFeatures />
                        <moduleDefinitions>
                            <moduleDefinition>
                                <friendlyName>Gallery Server Pro</friendlyName>
                                <defaultCacheTime>0</defaultCacheTime>
                                <moduleControls>
                                    <moduleControl>
                                        <controlKey />
                                        <controlSrc>GalleryServerPro.Web.Gallery, TechInfoSystems.GalleryServerPro</controlSrc>
                                        <supportsPartialRendering>False</supportsPartialRendering>
                                        <controlTitle />
                                        <controlType>View</controlType>
                                        <iconFile />
                                        <helpUrl />
                                        <viewOrder>0</viewOrder>
                                    </moduleControl>
                                </moduleControls>
                            </moduleDefinition>
                        </moduleDefinitions>
                    </desktopModule>
                    <eventMessage>
                        <processorType>DotNetNuke.Entities.Modules.EventMessageProcessor, DotNetNuke</processorType>
                        <processorCommand>UpgradeModule</processorCommand>
                        <attributes>
                            <businessControllerClass>GalleryServerPro.Web.GalleryServerProController</businessControllerClass>
                            <desktopModuleID>[DESKTOPMODULEID]</desktopModuleID>
                            <upgradeVersionsList>01.00.00</upgradeVersionsList>
                        </attributes>
                    </eventMessage>
                </component>
 

The reason I did it this way is two-fold:

1. The application I am porting from is already architected this way and I want to minimize changes.

2. The original app was this way because the Gallery user control can be thought of as a controller class whose job it is is to determine - based on query string - which user control to load. IOW, this control's primary job is to dynamically load the desired control. As such it has no UI and no need for a .ascx file.

As for what it looks like when dropped on a page, I believe it looks like any other module, since it *is* a user control and inherits from PortalModuleBase.

The original, unported application is an open source gallery and can be found at Gallery Server Pro.

Hope this helps,

Roger