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.

5 days 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.

5 days ago
Changed the status to
Archived
5 days 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]?

5 days 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;
5 days 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.

5 days ago
Changed the status to
Unassigned
5 days 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 days ago