Overview
Content
# config: {…}
The config: field is a list of entries describing feature- and
application-level settings.
# config:
# { name: linky, type: bool, description: autolink urls }
# { name: xy.title, type: str, value: "blog title" }
# { name: perm, type: select, select: 3=USER|2=EX|1=SUP|0=KERN }
PMD is about uniform feature lookup. And
plugin handling goes hand in hand with configuration management.
However it requires a structured field to avoid bulky definitions, yet
support enough variation.
Usually config: contains multiple indented lines, each being a
JSOL-dictionary.
name: |
associates some variable/constant/expression to a setting. |
type: |
A few common types may cover 90% of configuration needs.
</td>
</tr>
<tr>
<th><code>select:</code></tt>
<td>* Withselect: "aaa┃bbb┃ccc"` being the alternatives attribute for
combobox options.description:
bool/boolean |
would render as checkbox often. |
str/string |
for plain textual content. |
int/integer |
verifies the value to be numeric. |
select/multi |
defining a predefined list of defaults. |
| holds some elaboration on the key name. |
value: |
just sets a default |
Storage and key name:
Notably this scheme just defines a list of available options. It does not
prescribe if they're stored in an .ini, .json, xml or code file, or a database
perhaps.
Applications might utilize different stores even, and dispatch depending on
the name: syntax
- For example
name: ALL_UPPERCASE might become a code constant,
- While
name: sectioned.feature.option indicated an INI setting,
- Or
name: "$cfg.plugins[after][]" even a literal code target.
So names can be somewhat free-form. I'd avoid including the $ sigil
however, or spaces obviously. Mostly-alphunumeric and dotted keys are
certainly most versatile.
select: type and alternatives
The syntax for select: is
- preferrably
"alt|alt|alt"
- or with optional title
"1=title|2=alternative|3=…".
- Though implementations may allow to use
, comma and | dash.
- Or
: like = again.
Other fields and types
Other per-config attributes migh encompass
category: and class: for decoration or grouping.- Or
arg: and param: for defining commandline args rather than global application settings.
Other types might be
text for lengthy textarea-style strings),color for a color picker,file bringing up a file selection dialog- Or
table/csv/dict for supporting more complex (Excel-style) setting lists.
Regex tokenizer
You can get by with a somewhat simple regex extractor for this config
scheme. It's simply finding {…} pairs, then splitting key-value pairs,
and handling optional quoting.
Of course a stringent JSON-parser could be used. But that's obstructing
maintanability, and buys little performance-wise. (Plugin or option
management is rarely done during runtime; but confined to some admin
or installer UI.)
Purpose
Once config options are easily parseable, it quickly pays off to implement
a centralized option/admin UI. And it sometimes can be combined with plugin
configuration itself. Which is why plugin meta data defines this simple
scheme.
|