Learn More





Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesRecommended uses of Module Settings tablesRecommended uses of Module Settings tables
New Post
1/31/2014 5:14 AM

Hi all

I've just started out developing some small modules and I was wondering if there were any recommendations about when I need to use SQL to create a new table for the module for it's content, and when it is ok to just use the module settings fields.

The organisation I work for has lots of different departments that would need to be involved with any SQL database manipulation and it'll be quite a long process to get any modules we create onto the live site.

So it's tempting to use the module settings functions to store some data.

As an example, my next project is a small module which displays different content depending on various conditions on the page. 

As far as I can see there are 3 implementation options:

1) Hard-code the HTML for content options A and B into the module and allow the user to set the display conditions in the module settings panel - This doesn't seem right as any minor tweaks to the content HTML would mean needing to re-release the entire module.

2) Create an edit page for the module which has 2 text areas, A and B, and a settings page which allows the user to set the conditions - This makes sense to me but would require SQL and database changes to create the edit functions.

3) Put the editing boxes from point 2 into the settings page and allow the user to set the HTML as global or specific to this instance of the module, and add the display conditions - This is my preferred option but I don't know if it's wrong to put chunks of HTML into the module settings table, I've not seen any other modules that do this.

Does anyone have any thoughts on this?

Or maybe there's a totally different way to do it?

 Thank you

New Post
1/31/2014 7:15 AM
you may put any text into moduleSettings.settingvalue (for a single module instance) and tabmoduleSettings.settingvalue (for a module reference on a page), this should not affect DNN performance (unless you are adding thousands of rows) and you may use DNN API to edit and retrieve the values. Be aware that settings are cached in server memory.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group   European Network of DotNetNuke Professionals

Speed up your DNN Websites with TurboDNN
New Post
1/31/2014 9:08 AM

Thanks for your reply Sebastian

What are the implications of it being cached in the server memory?

I'm really not thinking a lot of data in the settings, just a small amount of html content to display on the page


New Post
1/31/2014 5:38 PM
ModuleSettings fields are varchar(MAX) format - so in terms of dnn side storage - you are free to store pretty much whatever you want in them.

In terms of caching - yes - module settings are cached - but the system has a pretty good flushing method that clears out items that are not regularly loaded.

The upside here ironically though is that if your module is regularly being called - you get all the performance improvement benefits of the dnn datacache without having to code for it yourself.

That said - given the amounts of data already being loaded into the dnn cache - a couple of small 2 to 4k html pages would have very little impact on actual system load.

New Post
2/3/2014 6:26 AM

Ah ok, that's perfect thank you!

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesRecommended uses of Module Settings tablesRecommended uses of Module Settings tables

These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?