Posted by: Néstor Sánchez
Tuesday, September 16, 2008 

I was reading a blog post that suggested a solution to finding the page where a module is on (http://blog.dmbcllc.com/2008/09/15/dotnetnuke-modules-finding-the-page-a-module-is-on/) and while the method is sound, it is not appropriate to be used in all cases. Let's see why:

1. The method retrieves all pages that exist at the portal level into an Array List. While at first sight it seems ok to do this, a portal with thousands of pages will of course create a big array.
2. The method iterates through all pages until it finds a module that has a desktopmoduleid that matches the desktopmoduleid of the searched module. On a portal with thousands of pages this is clearly going to be a long running loop, unless the module is found early in the iteration.
3. If the method is used to dynamically populate a link (as it is the intention of the blog author), the iteration will impact the portal everytime the modules that use the method are loaded.

It would be a useless observation, unless an alternative path is suggested. For this specific case, one option is that the searched module "informs" where it is located. This can be done in a few different ways:

• Using ModuleSettings (not tabmodulesettings), or
• Saving it to a table where the module keeps its configuration.
• Using a public method (i.e. themodule.utilities.tabid)

The first one requires that the calling module "knows" the name of the setting. This is easy when the developer controls both module.

The second one can be benefitial if the developer wants to use a SPROC.

The third one has the advantage of providing a clear contract, taking into account that the requirement is that only one instance of a specific module must exist and it also encapsulates the logic. There is a caveat, it would provoke an exception IF the module does not exist on a page. This can be gracefully handled by the calling module, i.e in pseudocode --> if themodule.utilities.tabid = -1 then ShowNotFoundMessage

As usual, there are many ways to solve a problem, but not every solution is appropriate in all cases. The job of a developer is to anticipate this and proceed accordingly.

Trackback Print

Tags:

Categories:

Location: Blogs Néstor Sánchez