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:
goto host:Languages and start the language editor
switch to a foreign language (German is installed by default)
replace all content from all entries with "xxxxxxxxxxxxxxxx" except command links, mark these with an asterik
goto a page, where your module is installed
check if there are english texts left not replaced by "xxx"
please check for messages from validation and the code as well (corfirms, ...)
if you found missing keys: complete your english resource files
goto the language editor and open the foreign resource files
click on "add missing entries"
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.
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.
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...
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) [;)]
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.
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.
leupold
Contributor
6015 Points
1197 Posts
Typical Issues in Custom Modules
Apr 08, 2005 08:05 PM|LINK
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:
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.
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:
Anyhow, modules are getting better and better - let's work together to get DotNetNuke going to fly.
Sebastian
gamma concept mbH
DeutschNetNuke = DotNetNuke in German
DNN Project UserDefinedTable
Bunce
Contributor
2085 Points
415 Posts
Re: Typical Issues in Custom Modules
Apr 08, 2005 10:16 PM|LINK
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
Geert
Star
10052 Points
2011 Posts
Re: Typical Issues in Custom Modules
Apr 08, 2005 10:42 PM|LINK
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
rodneyjoyce
Contributor
6080 Points
1216 Posts
Re: Typical Issues in Custom Modules
Apr 08, 2005 11:37 PM|LINK
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...
leupold
Contributor
6015 Points
1197 Posts
Re: Typical Issues in Custom Modules
Apr 08, 2005 11:50 PM|LINK
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:
Nobody ever said, web developement is easy (or he lied) [;)]
Sebastian
gamma concept mbH
DeutschNetNuke = DotNetNuke in German
DNN Project UserDefinedTable
uzi
Participant
1340 Points
268 Posts
Re: Typical Issues in Custom Modules
Apr 09, 2005 07:49 PM|LINK
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.
Oliver
wallew
Participant
1255 Points
251 Posts
Re: Typical Issues in Custom Modules
Apr 10, 2005 02:08 AM|LINK
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
mcsenow
Participant
1084 Points
218 Posts
Re: Typical Issues in Custom Modules
May 05, 2005 02:57 AM|LINK
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
DotNetNuke Modules Issue Tracker, Timesheet, MSSQL Reporting Services, Visitor Counter
rodneyjoyce
Contributor
6080 Points
1216 Posts
Re: Typical Issues in Custom Modules
May 05, 2005 11:43 AM|LINK
Hi
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.
mcsenow
Participant
1084 Points
218 Posts
Re: Typical Issues in Custom Modules
May 13, 2005 01:02 PM|LINK
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.
DotNetNuke Modules Issue Tracker, Timesheet, MSSQL Reporting Services, Visitor Counter