D 2018-07-04T01:46:39.874
L config
N text/x-markdown
P a44e7b1fb98f4f199400e84abb87150e07749412009364d80e3cb2a0424021bf
U mario
W 4123
## # 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](wiki/Plugin+Meta+Data) 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
<acronym title="JSON, but quotes optional">JSOL</acronym>-dictionary.
#### {
<table class="cnt-tbl">
<tr>
<th><code>name:</code></th>
<td>associates some variable/constant/expression to a setting.</td>
</tr>
<tr>
<th><code>type:</code></th>
<td> A few common types may cover 90% of configuration needs.
<table>
<tr>
<th><code>bool</code>/<code>boolean</code></th>
<td>would render as checkbox often.</td>
</tr>
<tr>
<th><code>str</code>/<code>string</code></th>
<td>for plain textual content.</td>
</tr>
<tr>
<th><code>int</code>/<code>integer</code></th>
<td>verifies the value to be numeric.</td>
</tr>
<tr>
<th><code>select</code>/<code>multi</code></th>
<td> defining a predefined list of defaults.</td>
</tr>
</table>
</td>
</tr>
<tr>
<th><code>select:</code></tt>
<td>With `select: "aaa┃bbb┃ccc"` being the alternatives attribute for
combobox options.</td>
</tr>
<tr>
<th><code>description:</code></th>
<td>holds some elaboration on the key name.</td>
</tr>
<tr>
<th><code>value:</code></th>
<td>just sets a default</td>
</tr>
</table>
#### }
## 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.
* Which allows syntax alternatives `[:=>]+` for key-value pairs.
* Same as shortened/aliased type names add some user-friendliness.
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.
Z 4d9ac9f842585d9b82783f4feae76094