Typical Issues in Custom Modules

Hi all Module Developers,

I would like to beg you to pay attention on the following issues I encountered frequently, when testing released modules for DNN3:

Object Qualifier
Please test your module, if it works at portals, that are using object qualifiers. It is not a big effort to set up a second portal for testing, using the same Database and an object qualifier.
Localization
Check the module in a foreign language. As I know, that not all are willing to translate their modules by yourself, you can use the language editor support for checking completeness:
1. goto host:Languages and start the language editor
2. switch to a foreign language (German is installed by default)
3. replace all content from all entries with "xxxxxxxxxxxxxxxx" except command links, mark these with an asterik
4. goto a page, where your module is installed
5. check if there are english texts left not replaced by "xxx"
6. please check for messages from validation and the code as well (corfirms, ...)
7. if you found missing keys: complete your english resource files
8. goto the language editor and open the foreign resource files
9. click on "add missing entries"
10. continue with step 3.
Check for missing localization keys of control titles
- Use key "ControlTitle_edit.Text" if the module key is "Edit" (pay attention on capitalization!)
Integrate your settings into module settings by using control key "settings"
integrate Module Help by adding Resource Key "ModuleHelp.Text"

Anyhow, modules are getting better and better - let's work together to get DotNetNuke going to fly.

Sebastian

Re: Typical Issues in Custom Modules

I'll add another issue I've found:

Please design your rmodule to account for multiple instances of it being places on the same page.

This means if you pass parameters in the querstring (ie for navigation, or control injection), the you should also pass the moduleID to ensure that *only* the module to which the action was targetted, will use it. Your module therefore needs to check that the moduleID passed matches the current moduleid..(Note: you can't use mid as a parameter name for this as its reserved for other actions, so I use ModID for example)

Otherwise you may pick up a situation where both modules are performing the same action, or loading the same data etc

It also avoids any conflicts with other modules who happen to use the same parameters in the querysting.

An alternative method is to load the control into pane by itself as a number of the core modules do.

Cheers,
Andrew

Re: Typical Issues in Custom Modules

Good points.

On the core team we develop now standard with the objectQualifier set to "dnn_".
I would strongly suggest to always do that to all module developers.

For localization there is now a setting in web.config to show any missing localization keys. They will show up as "RESX:<textkey-name>".

Geert

Re: Typical Issues in Custom Modules

Possibly another design consideration that developers are not always aware of:

Test the module with multiple portals, especially if it has user related functions (eg. get all users etc.)
I only have 1 portal and this is something that tripped me up when I moved to 2...

Re: Typical Issues in Custom Modules

Of cause, developers shall keep in mind to test all relevant situations - variing all parameters that might affect the module according to the core feaatures it relies on:

single portal installation, multiple portal installation
use in parent and child portals
use behind a proxy, if accessing external addresses
use with friendly URLs on and off
use with different browsers
...

Nobody ever said, web developement is easy (or he lied) [;)]

Sebastian

Re: Typical Issues in Custom Modules

One last item i'll add. Even though i'm guilty of a little bit of everything here ;)

Also test your modules with both a VirtualDirectory, and Root Domain setups.

I frequently find broken images and whatnot in my modules because the paths change for virtual directories.

Re: Typical Issues in Custom Modules

I am glad you brought this up. A list of common 'newbie' development issues is probably a great idea for newbie module developers like myself. Just like anything else, the more experinced guys have already had to fight the problems and know what to look for. Everyone has made very good points.

While we are on the topic, there is another thing that has bugged me in the past. Module developers not adhearing to the css classes for module elements. Sure you can edit the ascx file if you have to, but it sure would be nice for the tags to already be there.

Thanks again for making this point.

Wallew

Re: Typical Issues in Custom Modules

Sebastian -

5. integrate Module Help by adding Resource Key "ModuleHelp.Text"

Could you please elaborate on item 5 above? I could not find any info abouth ModuleHelp.Text in the DNN Developer guide.

Thanks

Re: Typical Issues in Custom Modules

If you add a record to the .resx file with ModuleHelp.Text, it will automatically populate the text according to your culture if you click on the Help icon in the module actions.

Re: Typical Issues in Custom Modules

rodneyjoyce -

Thank you. I tried it in the Visistor Counter module on my dnndev.icpconline.com and it worked. No more empty help. Yeah [Y]

It would be nice to have this ModuleHelp.Text documented in the DNN developer guide.

Re: Typical Issues in Custom Modules

no prob. I may be wrong but I think it is in the Locali(s)zation guide...