System Settings 2.0

[jbee]

System settings need a redesign...

Why?

• reduce "fix" costs (complexity budget)
• reduce cost of change (add/remove/organize settings)
• enable faster selective evolution of the platform
• move towards DB declared settings for better extensibility

How?

• more clear model with JSON values
• widely server driven (single point of change and truth)
• allow easy introduction of feature-toggles (needed to disable costly features by default that should be removed)
• simplify UI by using few generic concepts (assuming setting changes become more frequent as we move forward as a solution to ease disruptive changes while not having to drag along costly features that are not used by an installation)

Properties

The approach is to use only the SystemSetting entity (single table).

Static Properties

• default value (move to DB as JSON for consistency?)
• Java type (replaced by use of JSON API)
• confidential (encrypted)
• translatable (keep ?)

Data Properties

• value (JSON)
• name
• role (enum for feature, preference, ...)
• translations (keep ?)

Layout Properties

• type (enum text, drop-down, ...)
• page (string key; also key for title text)
• group (string key; also key for group text)
• label (string key; key for label text)
• attributes (for specific type in JSON, like pattern, options, ...)

Pages are essentially implicitly given by the properties of the settings.
This surely is limited in is capability when it comes to layout and overall UI look and feel. This, however, would exactly be a design goal.
Settings should be recognizable as independent switches and by using a uniform simple organisation users quickly can handle server settings even if they undergo constant change.

Validation

Validation based on JSON schema validation via user defined json-tree types

Migration

Analysis of settings types

• boolean
• string (+enum)
• string (Locale)
• string (Date)
• double
• integer
• object (the entire Configuration!?)
• object (SmsConfiguration)

After deliberating on how to best do the type conversion I found that there are opposing goals for a data (DB) driven settings and using exact (specific) types. One suggests that we don't know types while the other assumes it.
Looking at the above analysis I had the idea of simplifying types to just 3

• boolean
• string
• number
  The object cases always were abusing setting more so I think these should use the datastore in a protected NS instead. The rest is easily mapped to these three base types. the refinement to a type based on that can then be outside of the settings.

Java API

The SettingKey enum solution always leaves room for error when using keys with the wrong type conversion in a lookup. Also it is cumbersome to use. Suggested API is a Settings interface that acts as if it is a value object. We might implement it by making immutable copies of all settings at the beginning of a request which then-forth are used. This would be constructed from cached settings like now. Each setting gets a method in the interface. The JSON value to java conversion is part of the implementation.

interface Settings {
  int emailPort();
  String emailSender();
  //...
}

The SystemSetting class would be made "internal" as 99% of usages of settings should only be interested in the key-value property.
Only when settings are changed further properties are needed. This would be done via a dedicated parameter class.

Alternative Model

Introduce a SettingsPage object? Mainly this object would hold a JSON describing the page layout details.
While this has greater flexibility it also has higher complexity and costs.

Pros

• more flexible
• future proof as JSON is extensible

Cons

• more complex / costly to build
• higher complexity / cost of adding or removing settings and alike
• can be inconsistent and have phantom references etcetera