On this Page:
This approach has the following advantages:
- It is easy to find all settings of a service.
- The same settings can be re-used in several diagrams.
Only exception of this rule: Use the inline style definition when having a single setting in a specific context.
Naming Conventions for Settings
For | Use | Example |
---|---|---|
Single Settings | one class named Settings | |
Multiple Settings | multiple classes: SettingsSuffix | SettingsCustomer |
Documentation | use tagged value Setting Name to document how to use this setting. | Put in timeout in seconds: |
Setting vs. User Interface
Usage of a settings class is to be preferred, if the setting is a simple one, e.g "Customer:".
In place of settings, you could also implement a user interface. The usage of a user interface is preferable, in the following cases:
- The settings need enhanced validation (enumeration etc.).
- The settings are complex, e.g. three input fields which belong together.
Overview
Content Tools