History Page Raw
Overview

Artifact ID: e92682de46cdbe4f2d867f480488497b63fcfb6438ce2d7e8eab451ae017a0b5
Page Name:config
Date: 2018-07-03 20:44:28
Original User: mario
Mimetype:text/x-markdown
Parent: 711e1de1c5e9ac102fb18116336c94808410b757eeb8fc032b7f88e41cd04c72 (diff)
Next 4e70d205b92dfc304974d8cb99ec4c997dee1a0fb8092a76fd4a38b1808f6acd
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 configuration settings go hand in hand with plugin manageability. 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.