59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
|
<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
## `select:` 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.
|
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
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.
## 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.
## 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.
|