Re: Abstracting your module’s settings into their own class

Pretty nice. I would suggest that you modify your ReadValue sub so you only have one. Like so:

ReadValue(ByRef ValueTable As Hashtable, ByVal ValueName As String, ByRef Variable As Object, byVal VariableType as Integer)

Then have a VariableType enum for your different types (String, Integer, Date etc..) and just use a case statement inside your code.

Re: Abstracting your module’s settings into their own class

Great stuff Peter - the Settings page has always annoyed me (Nik K. wrote a great automated settings page almost half a decade ago!) - but I always cut and paste due to time constraints.. it's time I refactored!

Re: Abstracting your module’s settings into their own class

I also always use a custom module configuration class with the following additions:

1. Use generic method for obtaining setting from settings hash by key, substituting default value if setting does not exist:

Private Function GetSetting(Of T)(ByVal key As String, ByVal defaultVaue As T) As T
Dim obj As Object = _Settings(key)
If obj Is Nothing OrElse CStr(obj) = String.Empty Then
Return defaultVaue
Else
If TypeOf defaultVaue Is System.Enum Then
Return CType([Enum].Parse(GetType(T), CStr(obj)), T)
Else
Return CType(obj, T)
End If
End If
End Function

2. Cache the custom configuration class object in my module control base class (which inherits from PortalModuleBase).

3. Define in the costom configuration class any read only properties (such as template or shared resources folder) used by all controls in the module

Re: Abstracting your module’s settings into their own class

I actually wrote a suggestion for this about 3-4 years ago and logged it in Gemini! I think the old school method of having a collection full of settings needs to be replaced by a more featurefull settings class. Here's the code for how I do mine with a mini-example. You'll notice that I use generics and type conversion which allows me to persist more interesting information to my settings and use things like enums instead of raw values.

namespace FormFactor.Config {
public class SettingManager {
public DotNetNuke.Entities.Modules.PortalModuleBase Parent { get; private set; }
public SettingManager(DotNetNuke.Entities.Modules.PortalModuleBase parent) {
Parent = parent;
}

private const int DefaultFormID_DEFAULT = -1;
private const string DefaultFormID_INDEX = "DefaultFormID";
public int DefaultFormID {
get {
return GetValue(DefaultFormID_INDEX, DefaultFormID_DEFAULT);
}
set {
SetValue(DefaultFormID_INDEX, value);
}
}


private const ConnectionStringType ConnectionString_Type_DEFAULT = ConnectionStringType.WebConfigEntry;
private const string ConnectionString_Type_INDEX = "ConnectionString_Type";
public ConnectionStringType ConnectionString_Type {
get {
return GetValue(ConnectionString_Type_INDEX, ConnectionString_Type_DEFAULT);
}
set {
SetValue(ConnectionString_Type_INDEX, value);
}
}

private const string ConnectionString_Value_DEFAULT = "SiteSqlServer";
private const string ConnectionString_Value_INDEX = "ConnectionString_Value";
public string ConnectionString_Value{
get {
return GetValue(ConnectionString_Value_INDEX, ConnectionString_Value_DEFAULT);
}
set {
SetValue(ConnectionString_Value_INDEX, value);
}
}

public string ConnectionString_Evaluate() {
string ret = "";

if (ConnectionString_Type == ConnectionStringType.WebConfigEntry) {
string Section = ConnectionString_Value;
if (Section == "") {
Section = "SiteSQLServer";
}
ret = DotNetNuke.Common.Utilities.Config.GetConnectionString(Section);
} else if(ConnectionString_Type == ConnectionStringType.StringValue) {
ret = ConnectionString_Value;
}

return ret;
}



private T GetValue(string key, T defaultvalue) {
T ret = default(T);
object value = Parent.Settings[key];
if (value == null) {
ret = defaultvalue;
} else {
var TypeConverter = System.ComponentModel.TypeDescriptor.GetConverter(typeof(T));
try {
ret = (T)TypeConverter.ConvertFrom(value);
} catch {
ret = defaultvalue;
}

}

return ret;
}


private void SetValue(string key, object value) {
Parent.Settings[key] = value;
var MC = new DotNetNuke.Entities.Modules.ModuleController();
MC.UpdateModuleSetting(Parent.ModuleId, key, value.ToString());
}

}
}

Re: Abstracting your module’s settings into their own class

Peter

I did something similar in the Host settings area a couple of releases ago.

Re: Abstracting your module’s settings into their own class

A few things in "Settings" annoyed me:
- Problems of using strings instead of compiled names and their retrieving their default value (as described by peter)
- Writing too many UpdateSettings

So I designed my own Settings class which is not a collection (it has custom properties of the specific module), Before saving them, I serialize them into xml string, and by one command update the whole settings.
another benefit is that now I can store simple/complex but small data structures whitin module settings so there is no need to any data table:) .
The problem is settings column width is not large enough to hold a serialized xml string,so I developed a 3 column table to store my module's settings.





- Saving small/simple data structures into data tables