History Page Raw
Overview

Artifact ID: bab9a8bf5549ac683d45738605157c9e580964b3c8afae68d931464f602d2a35
Page Name:config
Date: 2018-07-03 20:48:31
Original User: mario
Mimetype:text/x-markdown
Parent: b05c0dc0124197f4e10501d371cecd5f306a26ecae34aed257e12d40f56e2d6f (diff)
Next 57a4d9c434cbb12c654b1e6b736de2547d243374dcae2fe70094a19f97d9ba7a
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.

  • 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.