quick question about settings

[OogyWaWa]

So, I'm just wondering how settings are generally implemented. For example, with .net, you have the .settings XML file. I understand reading and writing to it just fine and know ways of getting it to control how the program works, but I'm just wondering what the common practice is when implementing these settings. Do you just use basic flow control (if/else, swtich, etc.) based on the possible settings?

Ex)
Settings file:
UserType = Admin;

In the program somewhere:

If(settings.UserType == Admin) { button.hidden = false; }

I don't know, but this just seems kind of ugly to me. On top of that, if you had a program that has a billion settings, this could get bulky. So, how is this stuff usually done?

 

[DaveSimmons]

admin_button.hidden = (settings.UserType != Admin ) ;



But seriously, ifs or cases or assignments are just what you have to do. You can group them together as much as possible, and try to apply them as early as possible.

 

[Markbnj]

Wow, big question. I'd say it almost always ends up getting messy. It's not really just a matter of UI state, but which paths of execution are allowed or required, etc. There are a couple of components to how I usually approach this in a .net app.

First, each independent component that requires configuration information (these are usually assemblies) defines one or more types derived from ConfigurationSection and any related element and collection types to fully define the set of options. The hosting assembly is required to implement these sections in its .config file.

The dependent assembly will take an instance of the root ConfigSection for that assembly at initialization, read the data from it, and store it in some internal structure.

That takes care of getting the config information passed around to all the assemblies that need it.

Second, I create abstractions to represent "what you can do/what the program should do" (an operation/action) and another set of abstractions to represent the things that must be true for the operation to be allowed (requirements). Together these are a "policy." The operation can be any abstract idea: turn on a control, allow a feature to be activated, switch to a certain screen resolution, whatever. The requirements can be permissions, options settings, environment variables, or any other trigger. The key idea is to encapsulate the set of comparisons that leads to a decision so that UI code, for example, is making clean, self-descriptive calls like:

if (Policies["AllowEdit].IsSatisfied())
EditButton.Enabled = true;

The third thing I usually do in the case of UI code is to create abstractions that encapsulate control state. So if I have a dialog or page with a number of controls on it, I have a class that checks all the policies for that page and returns a ControlState object that iterates through the controls and sets them up accordingly. Again the idea is just to keep all these concepts compartmented and prevent them from littering the UI code and duplicating logic all over. There are many, many ways to approach it, but that's a general outline of what I do.

 

[DaveSimmons]

^ that seems like a good approach, and applies the settings (to create policy) immediately instead of waiting until it's time to render controls or run code blocks.

If any parsing or validation of settings is needed that also happens in a single known location (your policy) instead of being scattered in different areas of the code.

Pardon me while I steal your ideas for my next project . . .