Ein paar YAML Form Framework Lösungen

In diesem nachfolgenden Text habe ich ein paar Problemlösungen zusammengetragen, die mir bei der Arbeit mit YAML-Formularen und der damit erzeugten Feldinhalte untergekommen sind.

Problembeschreibung:

Z.B. in einigen PHP-basierten CMS wie Joomla, Wordpress, Gravity, Drupal, Magnolia wo z.B. durch das Templateframework Gantry 5 u.a. YAML als Formular Framework verwendet wird, ist das Erstellen von Formularen dank dieser Konfigurationssprache recht einfach. Allerdings kann man manchmal auf Probleme stoßen, bei denen eine Lösungsfindung nicht recht einfach ist. Grund dafür ist, dass die Dokumentation der Markup-Language YAML mit ca 80 Seiten ein Schwergewicht ist und sperrig zu lesen. Ein weiterer Grund ist, dass die Google-Suche nicht immer brauchbar zu Lösungen führt.

Hier sollen deshalb ein paar kleine Tipps folgen, die das eine oder andere Problem lösen.

Lösung für das Problem Zeilenumbrüche

Wenn man in YAML z.B. eine Feldtyp textarea.textarea erstellt und diesem Textfeld eine Default-Wert übergeben möchte der mehrzeilig ist, z.B. weil man zeigen will, dass pro Zeile ein Keyword einzutragen ist, dann kann man nicht einfach in den Default-Text mit Enter arbeiten. Enter erzeugt eine neue Zeile und damit beginn in YAML ein neuer Knoten. Das führt zwangsläufig zu einem Fehler. Lösungen gibt es dazu gleich einige in YMAL. Die einfachste ist den Zeilenumbruch mit \n zu codieren. Das alleine wird aber ignoriert. Damit der YMAL-Interpreter das korrekt auswertet, muss der gesamte String in doppelte Gänsefüsschen gesetzt werden! Keine Hochkommas verwenden!

Hier mal ein Codebeispiel für die Anwendung:

    ToolTips:
      type: textarea.textarea
      label: ToolTips
      description: Defines the Tooltipp. Each item in a new line.
      default: "section1\nsection2\nsection3"
    next:
       ...

Lt. YAML-Specification gibt es 8 weitere Möglichkeiten. Das macht YAML zwar mächtig, aber ist ein Grund für die Notwendigkeit dieser gigantischen Dokumentation. Eine schöne Zusammenfassung z.B. durch die Verwendung von block scalar styles wie > oder | ist im stackoverflow-Forum beschrieben. Ein Beispiel mit block scalar style | sehe dann so aus:

    ToolTips:
      type: textarea.textarea
      label: ToolTips
      description: Defines the Tooltipp. Each item in a new line.
      default: |
        section1
        section2
        section3
    next:
       ...

Wichtig dabei ist, dass alle Zeilen die den Inhalt ausmachen entsprechend mit der korrekten, gleichen Anzahl Leerzeichen eingerückt werden, ansonsten käme es auch hier wieder zu Parsingfehlern.

Unter Gantry 5, wird ein so vorbefülltes Area-Textfeld zwar korrekt gelesen und als Default-Wert angezeigt, aber wenn man dieses Formular speichert, wird der Feldinhalt dann in o.b. "\n"-Schreibweise mit einfassenden Gänsefüsschen und ohne |-block-scalar gespeichert.

Lösung für störende Hochkommas bei SASS/LESS/SCSS

Wenn sie z.B. in einem Formularfeld ein Float-Wert pflegen wollen, z.B. wenn Sie für ein Wasserzeichen-Hintergrund eine opacity-Wert benötigen, dann legen Sie dafür z.B. ein Feld vom Type input an. Hier geben Sie beispielsweise 0.25 ein. Im ihren SASS-Stylesheet-Scripten wollen Sie nun diesen Wert für die Hintergrundgrafik verwenden, beispielsweise so:

opacity: $extension-bkgd-opacity;

Hier entsteht jetzt eine Problem, denn SASS generiert daraus diese CSS-Ausgaben:

opacity: '0.25'

Die hier sichtbaren Hochkommas stören die Browser aber bei interpretieren des Opacity-Wertes, weil ein Float-Wert und nicht ein String erwartet wird.

Das Problem kann man jedoch im SASS lösen durch die Verwendung der Funktion unquote(). Das sieht angewendet dann so aus:

opacity: unquote($extension-bkgd-opacity);