Sorry, we don't support your browser.  Install a modern browser

Nameless stateless blueprint fields#141

F

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.

4 years ago

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.

4 years ago
Changed the status to
Archived
4 years ago
F

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]?

4 years ago
F

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;
4 years ago

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.

4 years ago
Changed the status to
Unassigned
4 years ago
F

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

4 years ago