Artifact ID: | b05c0dc0124197f4e10501d371cecd5f306a26ecae34aed257e12d40f56e2d6f |
---|---|
Page Name: | config |
Date: | 2018-07-03 20:47:43 |
Original User: | mario |
Mimetype: | text/x-markdown |
Parent: | b3031cfa799107b2092e89ed3b9c3d20dd009c1bb0957fb95e0a5d2f5425ce43 (diff) |
Next | bab9a8bf5549ac683d45738605157c9e580964b3c8afae68d931464f602d2a35 |
# 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.
The
name:
associates some variable/constant/expression to a setting.A few common
type:
names often cover 90% of configuration needs:bool
/boolean
would render as checkbox often.str
/string
for plain textual content.int
/integer
verifies the value to be numeric.select
/combo
defining a predefined list of defaults.
With
select: "aaa|bbb|ccc"
being the alternatives attribute for combobox options.description:
holds some elaboration on the key name.And
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:
even. For instance name: ALL_UPPERCASE
might become a
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
certianly most versatile.
select: type
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 migt be text
(lengthy textarea-style strings), color
(color
picker), file
(filedialog), table
/csv
/dict
for supporting more complex
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.