Application Configuration - add properties

[smalers]

It would be helpful if the application had a general list of properties that could be referenced with ${property} notation. This has worked well in TSTool as a global list of properties that are available to every command. This can simplify configurations. For example, data paths that use URLs could use ${dataserver} rather than https://data.openwaterfoundation.org. This would also allow configurations to be moved between servers by changing a property in one place rather than many lower-level configuration files.

This feature and the logging feature would be useful to show the TriLynx people.

I recommend the following.

Add global properties list

The global list of properties could be stored with the application. However, this requires that code that evaluates properties is aware of the application, which would not be good. A better solution is to have a static global variable in a general class, which could be retrieved using a static method like getApplicationProperties. In TSTool, much of the work is done in a "time series processor" but we don't have something similar in the InfoMapper. I suppose that the global data could be in a general class like Application rather than InfoMapper or tied to a "session" instance.

To be clear... care needs to be taken to manage a global list of properties but not be specific to InfoMapper application.

Add properties to configuration

The application configuration JSON file could be enhanced to have a top-level properties property, similar to what is used for layers and other configuration data. The value would be a list of properties of any type. Typically this is implemented as hashmap (dictionary) in code. Nulls are allowed as values and any object type should be allowed as a value.

Add built-in properties

The configuration file would initialize user-defined properties. Additionally, built-in properties could be automatically defined at start-up that are useful and might be updated as the application runs. For example, built-in properties could include the startup application URL, whether a mobile device, etc. For TSTool I decided to use MixedCase rather than camelCase for property names because it is a bit more user-friendly and technology-agnostic. See the TSTool properties in results for examples of names.

Care must be taken not to rely on such properties in low-level code (because that code would break if used outside of the application). However, if it is clear that low-level code depends on the application, the properties could be used if found. The main use of the properties is to allow configurations and workflows to use the properties, and make configurations simpler and more flexible.

Add a widget for viewing the properties.

TSTool has a Properties table in the results that shows the values of properties. This is useful for troubleshooting and also shows the built-in properties that can be used in workflows. I recommend creating a widget like applicationProperties that will display a table of properties, similar to TSTool (see below). The Property Type is a recent addition and makes it easier to know how a property is handled when converting and formatting values, for example string to date/time and double. It also shows when a type is a class such as DateTime. In TSTool the table is not editable. There may be some value in allowing edits of properties, but that can be done later. It is probably better to provide a form for editing, such as run-time enabling/disabling of certain features like log level for debug messages.