Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 11 Nächste Version anzeigen »

config.json
{
    "coreType": "print-core",
    "friendlyName": {
        "de": "Name",
        "en": "Name"
    },
    "extra": {
        "print": {            
            "types": [
                "element"
            ],
            "children": [],
            "parents": [
                "content",
                "container",
                "column"
            ],
            "variants": [
                "content-neutral"
            ]
        }
    }
}

Die config.json dient zur Konfiguration des Elements im Context des PrintDesigners. Damit das Element gefunden wird, muss eine config.json mit den coreType print-core in dem view-Ordner (src/View/MyView/views/myviewelement/config.json) existierten.

Die Konfiguration für die Print-Themen werden in extra→print erwartet.

KeyBeschreibung
source(optional)
Hier wird der EntityIdentifier der Tabelle für den Quelldatensatz erwartet. Es wird davon ausgegangen, dass das Plugin selbst diese Entity in Lib/Entity definiert.
template

(optional)
Es kann eine Datensatzvorlage für dieses Element hinterlegt werden. Falls dieser Key befüllt wurde, wird beim Modal für das Erstellen auch die Option angeboten, den Datensatz mit der Datensatzvorlage neu anzulegen.

types

Keywords, die von children und parents verwendet werden können. Diese Option beschreibt das Element. Gebräuchliche Keywords sind:

  • element → ein Inhaltselement ohne Kindelement. Zum Beispiel Text, Bild oder Abstand.
  • container → Ein Element, welcher Unterelemente wie Spalten erlaubt. Zum Beispiel Container.
  • column → Eine Element, welches nur in einen Container platziert werden darf. Zum Beispiel Spalte.
  • page → Ein Element, welches auf oberster Ebene erlaubt ist und direkt zum Inhalt (PrintPage) verknüpft werden darf. Zum Beispiel die Seitenbereiche Kopfbereich, Seiteninhalt oder Fußbereich.
childrenKeywords, die definieren, welche Elemente als Kinder des Elements erlaubt werden.
parentsKeywords, die definieren, in welches Element das Element erlaubt wird.
variants

Die css-Variante für den designer-node aus, zum Beispiel, admin-styleguide/component/designer-core/_layout.scss. Gängige Varianten sind: header-primary, header-secondary

Für die Daten des Views sollte eine Entity erstellt werden. Beim Erstellen eines Elements werden dann die Datensätze aus dieser Tabelle zur Auswahl angeboten. Mit dieser Entity wird dann auch beim Verarbeiten des Views gearbeitet.

Hinweis: Im cms werden diese Daten in einer Structure.json definiert und dann in der odm-Spalte des Views gespeichert. Hier wird stattdessen eine tatsächliche Entity erwartet.

Es kann eine Datensatzvorlage für dieses Element hinterlegt werden. Der eingetragene Identifier für das Template sollt dann auch ein Template definiert haben und dieses in der widget.json hinterlegt sein.

Template in widget.json
// Auf Tabellenebene
"configuration": {
    "FrameworkTemplateTemplate": {
        "TemplateIdentifier": "definition:plugin/remote/brandbox/print-layout-standard/src/View/MyView/Lib/Structure/MyViewemplateDefinition.json"
    }
},

In der Engine.php wird eine public function mit dem Namen des Views erwartet. Als Eingabeparameter wird \Brandbox\PrintCore\PrintDocument\Render\Lib\Struct\ScopeElement reingegeben und als Rückgabe wird ein \Brandbox\PrintStyleguide\Entity\PrintElementAbstract erwartet.

Debug-Hinweis: Die Methode aus der Engine.php wird in \Brandbox\PrintCore\PrintDocument\Render\Manager::getElementResult via \Brandbox\Framework\Brandbox\Routing\Main::getResult aufgerufen.

Man sollte beachten, dass die erstellten Tabellen auch in einem Rollenschema hinterlegt wurden. Meist in der App in welcher der View liegt. Engine-Methoden brauchen keine Security-Definition, da der view ohne Rechtecheck aufgerufen wird (die Eintity unterliegt allerdings noch dem Rechtesystem).

Für Container-Elemente gibt es mit \Brandbox\PrintLayoutStandard\View\PrintContainer\Lib\Request\ContainerAbstract eine Möglichkeit mit einem extend auf \Brandbox\PrintLayoutStandard\View\PrintContainer\Lib\Request\ContainerAbstract::getContainer und \Brandbox\PrintLayoutStandard\View\PrintContainer\Lib\Request\ContainerAbstract::getContent zuzugreifen.

Container-Element müssen ihren Inhalt selbst über \Brandbox\PrintCore\PrintDocument\Render\Manager::getElementResult sammeln.

Wird nicht mehr benötigt, da beim Verarbeiten des Elements ein SG-Element erwartet wird.

  • Keine Stichwörter