Non-interactable fields (like gap
, line
, icon
, info
, headline
etc.) should be addable without defining a name for it. That way it can be combined with it’s shortcode to create a neat one-liner.
Example currently:
headline4:
type: headline
label: some headline
gap31:
type: gap
width: 1/8
some_field:
type: text
width: 3/4
# and other stuff
gap32:
type: gap
width: 1/8
With nameless declaration:
headline: some headline
gap: 1/8
some_field:
type: text
width: 3/4
# and other stuff
gap: 1/8
Not only will it look cleaner, When inserting fields afterwards one doesn’t have to get creative with naming conventions etc.
This idea came up a few times already and we’d love to integrate it.
Unfortunately the syntax is not possible as the last gap
key will override the first in the YAML syntax. It is not possible to have two lines with the same keys in a YAML dict.
Just as an idea, would a regex-replace before parsing help in this case? as the syntax for the keyword ‘gap’ is always gap: [either newline, or shortcode value]
?
if there is file-string control, one can include this snippit to solve the problem I guese:
$c = 0;
$replacement_tags = ['gap', 'line', 'info', 'headline', 'icon'];
foreach ($replacement_tags as $tag) {
$yaml = preg_replace_callback("/($tag)\s*(:)/", function($match) use(&$c) {
return $match[1].$c++.$match[2];
}, $yaml);
}
return $yaml;
That would work, but is quite a hack that will be unreliable if for example the key gap
is used as a property of a custom field.
But your suggestion gives me an idea: If we ever switch to a different YAML library, we could implement this feature there. That’s not going to happen any time soon, but maybe we can do it at some point.
Looking foreward to that moment :D
And yep, I forgat about custom-fields. That is difficult to tackle without pre-parsing/partially-parsing the yaml-file indeed.
If there is a possibility to custom-handle duplicate keys, several other problems might be solvable as well. So hopefully it’ll be sooner than later