Storing Initialisation Data in a Strict Typedef

[Zyl]

Hi all !

I mainly use XML files as configuration file for my applications. And then use flatten/unflatten from XML to populate a configuration cluster...

I've made a routine which creates the configuration file if it has been deleted by the user. In that case the XML file is create with default values.

I usually 'store' these values in the strict type definition of my cluster (see In Strict Typedef png). I was wondering if it was a good idea ? Or should I explicitly bundle the values in my code (like in Init png) ?

[mje]

I have very little experience with the flatten XML primitives so I'm curious, what happens if the XML doesn't match the typedef? Say you're typedef changes, or a user modifies the XML? Do the primitives try their best to match what they can or is everything lost?

[george seifert]

If you reorder the elements in the cluster you could lose the values. At least that's been my experience.

George

[PaulL]

We also use XML files for storing configuration. I think this is a great solution.

I do not think it is a good idea to use the default values of the typedef to serve as default configuration values, since this is very unreliable and difficult to mainintain. In particular, it means that the developer has to edit the source code (and rebuild the application) to change the default values. Moreover, one has to have access to the source code even to see what the default values are (or maybe you run the editor and view them there?).

Our approach is instead to include an additional file for each configuration (e.g., MyConfigurationDefault.xml pairs with MyConfiguration.xml). Associated with the default files we include "Restore Page Defaults" and "Restore All Defaults" buttons in the configuration editor. (We simply read from the Default files as appropriate.) This has worked quite well. (Note that if someone wanted just to know what the default values were they could also just open the XML file; in practice we just read them in the configuration editor.)

If a user were to blow away the entire ConfigurationFiles directory (this hasn't happened to us) reinstalling the configuration files (which has its own version so that reinstalling the configuration does not necessarily reinstall the rest of the application) restores the original files.

In short, I advocate:

1) Supporting recall of default configuration values in your configuration editor.

2) Storing default values in files in the same fashion you store the user-edited values.

[What this means in practice is that to set the default values we open the configuration editor, set the values to be the defaults we want using the editor, save the configuration, and then copy the resulting files as default files. Done.]

[crelf]

As an aside, have you looked at EasyXML? It's awesome.

[Zyl]

I seem to remember a problem with this route (this may be going back a few versions of LV) where if you modify the typedef you lose all your constants.

I think in my case I had the typedef as a constant on the block diagram (it contained only booleans) and sometimes the booleans would all reset behind my back if the typedef was changed. This was LV2009 if my very rusty memory serves me correctly. This was annoying as the change happened invisibly and lead to some quite subtle logic bugs.

To be safe I think the other method you propose is a bit less likely to get you burned.

Hi Neil,

If you drag'n drop the cluster on your diagram, the constant created will keep the values set in the control definition. In LV 2011, it seems that, even if you modify the cluster, the set values are kept while the new values (from the new added controls) are set to 'void'.

As my cluster is only used as a constant for initialization values, if I modify it, I only have to check it once in my code... But indeed, for a question of 'security', I guess it's better to explicitly bundle constant values into the configuration cluster.

We also use XML files for storing configuration. I think this is a great solution.

I do not think it is a good idea to use the default values of the typedef to serve as default configuration values, since this is very unreliable and difficult to mainintain. In particular, it means that the developer has to edit the source code (and rebuild the application) to change the default values. Moreover, one has to have access to the source code even to see what the default values are (or maybe you run the editor and view them there?).

Our approach is instead to include an additional file for each configuration (e.g., MyConfigurationDefault.xml pairs with MyConfiguration.xml). Associated with the default files we include "Restore Page Defaults" and "Restore All Defaults" buttons in the configuration editor. (We simply read from the Default files as appropriate.) This has worked quite well. (Note that if someone wanted just to know what the default values were they could also just open the XML file; in practice we just read them in the configuration editor.)

If a user were to blow away the entire ConfigurationFiles directory (this hasn't happened to us) reinstalling the configuration files (which has its own version so that reinstalling the configuration does not necessarily reinstall the rest of the application) restores the original files.

In short, I advocate:

1) Supporting recall of default configuration values in your configuration editor.

2) Storing default values in files in the same fashion you store the user-edited values.

[What this means in practice is that to set the default values we open the configuration editor, set the values to be the defaults we want using the editor, save the configuration, and then copy the resulting files as default files. Done.]

Hi Paul,

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money !

As an aside, have you looked at EasyXML? It's awesome.

Hi Crelf,

I took a look at EasyXML. This tool is very powerful when you need to respect some XML schema compatible with the rest of the world (which is not the case of Flattent/Unflatten to/from XML LV functions ; only LV understandable).

Edited October 22, 2012 by Zyl

[Darin]

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money !

When I have a file that I would prefer not be deleted by the user (templates, default config, etc.) I usually place the contents inside a string constant inside the program and recreate it that way. One fewer file hanging around, and no chance of a user "accidentally" deleting (or modifying) it.

Other than that I agree with Neil: Explicitly bundle. Remember they are called "TYPE"-definitions, they are intended to define type and not value. It is tempting, very tempting, in fact very, very tempting to use those constants to hold values. Works great if the TD never changes, but a TD which never changes, well that is really just a plain old constant.

[PaulL]

Hi Paul,

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money !

Well, I admit our situation is relatively simple since we don't widely distribute our software. I would still use the same approach even if we did, however, for the following reasons:

1) Users interact with our configuration files via a configuration editor so they are really not likely to delete the files.

2) If a user does delete the files the user can restore them simply by rerunning the installer. (Of course, this means the user has to have the ability--permissions and skills--to run the installer, but that seems to be a reasonable expectation given that it is common practice in the computing world today. If as a user I mess up an installation of an application I expect to repair the installation or reinstall the application.) We would require the same procedure if a user deleted the executable file. [Even if I had a reason not to give the user the installer I would certainly include the configuration files in the deliverable as data files to store in a safe place in the event of an emergency. I'm not putting anything secret in the configuration files.]

3) I don't want to have to edit my source code every time the default values change.