Home » DotNetNuke - Module Development » DotNetNuke Modules – Retrieving Settings

DotNetNuke Modules – Retrieving Settings

ppl-wom-018 On Monday we discussed how to save setting information for our modules.  Today we want to pick back up where we left off and deal with retrieving that information, both in the LoadSettings() method and in the view module.

The Primary Method of Retrieval
The main retrieval method is the Settings property that is available in both the view and the settings module.  This is an indexed property that takes the key we specified in the Update methods as the indexer and returns the string that we saved as the value.

Behind the scenes, this property looks in the instance-specific settings and then in the global settings for the module and retrieves the data for us.  Since the property is set up as a hash table, all return values are typed as objects.  You’ll need to cast them to strings before you actually do anything with them.

Alternate Properties
You can also use the TabModuleSettings[] property and the ModuleSettings[] property to get the specific information.  The only reason I can think that you might want to do this is if you managed to make the key the same for a global setting and a module instance setting.  But that wouldn’t be very smart, and my naming convention for the keys makes that practically impossible.

Limitations …
The last bit of information you need to know about module settings is that the value can only be up to 2000 characters long.  At the risk of sounding like Bill Gates, 2000 characters ought to be enough for anyone.

But of course it isn’t always.

… and Solutions
I’ve only had one instance where I needed to store more than 2000 characters and fortunately I was reasonably sure that 4000 characters would do the trick.  So, I just split the data between two keys and stored half in one and half in the other.

The other solution, of course, is to store this information in your own table where you have control over the size and/or can delete rows as the data shrinks.

 

Other post in DotNetNuke - Module Development

Related Post

  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • DotNetNuke Modules – Module SettingsDotNetNuke Modules – Module Settings Since each instance of a module that we put on a page should be able to have it's own configuration information, it is necessary to have some place that will allow us to configure […]
  • DotNetNuke – Modules – Portal Specific ModulesDotNetNuke – Modules – Portal Specific Modules Many of you won't care too much about creating Portal Specific Modules because you'll be creating modules for an environment that only has one portal. However, if you are creating a […]
  • DotNetNuke – Modules – Linking within the moduleDotNetNuke – Modules – Linking within the module Now that we have the module skeleton up and running and we have a data access layer, the next thing we need to look at is specific functions you may need to use from within your code. One […]
  • DotNetNuke Modules – Making Content PortableDotNetNuke Modules – Making Content Portable The last main feature of module development that we need to discuss is the implementation of IPortable.If you've ever worked with other content management systems in a corporate […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.