History Page Raw
Overview

Artifact ID: 4e70d205b92dfc304974d8cb99ec4c997dee1a0fb8092a76fd4a38b1808f6acd
Page Name:config
Date: 2018-07-03 20:45:15
Original User: mario
Mimetype:text/x-markdown
Parent: e92682de46cdbe4f2d867f480488497b63fcfb6438ce2d7e8eab451ae017a0b5 (diff)
Next b3031cfa799107b2092e89ed3b9c3d20dd009c1bb0957fb95e0a5d2f5425ce43
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 filed 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 or code file, or in the database or elsewhere.

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.