4

We need to customize a desktop application at compile time. Users cannot change the configuration. Only developers and release managers can do it.

The configuration is a little complex. There are more than 10 modules. Each module needs configuration including values, capability flags, etc. We have 5 configuration groups called profiles.

Now, I shall choice one of two options. First one is programmatic approach. We can create configuration interfaces for each module and implement them for each profile. The alternative is that using configuration files. I like programmatic approach due its flexibility (e.g we can inherit a profile from another one). Also, it provides compile time check. But configuration files (like XMLs) are easy to maintain and understand.

Maybe, a mixed approach will be the best. But, I'm not sure how to do that. Have you any idea?

Thanks.

Improve this question
4
  • Could you provide more details on the technologies you use? Depending on that, there might be frameworks or libraries to make the solution easier. – superM Apr 28 '16 at 14:36
  • @superM We use C++ and Qt framework. – Q Q Apr 28 '16 at 14:40
  • So once the application is compiled, you don't want users to modify these configurations/settings. Right? Would these configuration files be bundle in the release? I mean, are they packaged? – Laiv May 11 '16 at 6:48
  • @Laiv yes, the configuration files would be packaged with application and users cannot change them. – Q Q May 11 '16 at 14:20
1

The big benefit of a configuration file, be it xml, json, ini, is that it separates data from behavior. This can help keep it readable. You can do this with code as well; you're just not forced to do it.

If you'd prefer to stick with configuration files, a way to meet your need to secure your configuration would be to compile your configuration in some way. This could be anything from obfuscating to encrypting to zipping and password protecting. None will be perfectly secure; neither is code, but should keep the casual user from fiddling with settings.

Configuring in code can be kept simple, but requires discipline. Construction or creational patterns can be leveraged for this. If you have the time to write one you could go as far as creating a DSL (Domain Specific Language) builder.

Improve this answer
2
  • 2
    You can separate data from behavior with a configuration class. In fact, this is what actually happens in practice; the difference with a configuration file is that the configuration class gets populated from the data in the configuration file. – Robert Harvey Apr 28 '16 at 15:10
  • Using a domain specific language may give a complete solution. But effort of a creating a DSL would be overkill for our project. – Q Q Apr 29 '16 at 7:20
0

I have an idea for mixed approach. We may generate configuration classes from configuration files. I imagine such a mechanism: Each module has a xsd schema for its required configuration. When the schema is changed, the configuration class will regenerated automatically. So, other classes will use configuration programmatically.

Profiles will have xml configuration files for each module. XMLs could be validated against XSDs. In the core application, a profile manager will load configuration xmls and pass them their modules. So, the configuration could be maintain easily playing with XMLs.

Improve this answer
2
  • So this XML wouldn't ship with the product, only the compiled configuration classes that resulted from code generation. Essentially resulting in compiled configuration. – candied_orange Apr 29 '16 at 13:22
  • 1
    Looks like these XML are patterns. Every patterns (XML) applied to the same code results in a customized release. Idea sounds nice due to you are normalizing your configuration files (via XSD). On more good thing is that there's a window open to a future/possible tool to manage these files. XSD is the only you need to build up such tool. It also make easier the versioning management on SCM (if the programmatic part of the hybrid solution is flexible enough to hold down-grades). If you are going to hybrid solution, make sure that programmatic part is as simple/flexible as possible. – Laiv May 11 '16 at 7:15
0

Pure config file approach that allows inheritance:

Since you're looking to have a set of parent configurations that can be inherited from, could you set up a two tiered configuration file system? Have a "master" and a "specific" file, and if the master and the specific define the same configuration value, then the specific file's value is used.

This isn't a new idea - think css, apache's main config and .htaccess, and I'm sure many other technologies also.

A slight variation of this that you see with git's config files and any bash based config files is the idea of "sourcing" another file (including it, as in inheritance) - At the start of one file, you indicate that it extends another, and when your file is being read, the "extend such and such a file" statement means "stop reading this file, process all of such and such a file, then continue reading this file".

This lets you have any number of levels of inheritance.

Improve this answer
-1

Here is another mixed approach.

I would ask what often changes. Those values can be put in a excel or spread sheet like file. That field will have labels, units, and valid ranges in it for each editable value.

The not often changed can go into code. This can go into use in envirment classes. The classes let use cases run, but take are for one envirment the system could be in. It will new up the objects needed (here is the envirment of the system assumption) . Then, return values and parameters are passed into methods. The class should not have any ifs or loops.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.