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 34 Aktuelle » 

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

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.

Key

Beschreibung

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.

children

Keywords, die definieren, welche Elemente als Kinder des Elements erlaubt werden.

parents

Keywords, 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

features

Für welche Features sollten in der Bearbeitenansicht Felder zur Pflege dargestellt werden. Für Keys siehe auch Print-Features.

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\PrintCore\PrintDocument\Render\Lib\Struct\ElementResultAbstract erwartet. Render\Lib\Struct\ElementResult für die Rückgabe eines PrintStyleguideElements und Render\Lib\Struct\ElementResultList für die Rückgabe mehrere PrintStyleguideElement Element in einem Array.

Über ScopeElement→context stehen dann auch die Einstellungen aus dem Generierungsdialog zur Verfügung. Zum Beispiel language um hypenate für die Silbentrennung zu befüllen.

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

Es ist möglich, Einstellungen für einen View zu definieren. Diese Einstellungen werden in der View-Methode im ScopeElement als $settings in Form eines Arrays mitgegeben.

Um Einstellungen zu definieren, sollte parallel zu der config.json des Views auch eine Datei liegen, die "StructureDefinition.json" benannt ist. Beispiel: View/PrintParagraph/views/paragraph/StructureDefinition.json. Die Struktur der Datei sollte dem Schema der structur.json folgen.

Es ist möglich, einen Quelldatensatz in der StructureDefinition.json zu definieren. Falls ein Quelldatensatz definiert wurde, wird in der Bearbeitenansich des Elements in den Einstellungen ein Auswahlfeld dargestellt, mit dem es möglich ist einen Datensatz auszuwählen, zu erstellen oder zu bearbeiten.

Quelldatensätze werden für die Verarbeitung im View mit den Settings zusammengeführt. Der Quelldatensatz überschreibt die Felder der Einstellungen, bei denen der Identifier in der widget.json und der StructureDefinition.json gleich sind. Das wird technisch mit einem array_merge gemacht.

Um einen Quelldatensatz zu definieren, erstellt man zuerst eine neue Datenbanktabelle und legt entsprechend auch eine widget.json an. Danach fügt man in der StructurDefinition.json ein Feld mit dem Identifier source an und definiert es als Input/ForeignKey auf die neu angelegte Tabelle. Das Feld source wird nun automatisiert mit den Einstellungen und dem Element verarbeitet.

{
    "identifier": "source",
    "label": "i18n:View/MyViewPackage.TranslationKey",
    "type": "Select",
    "configuration": {
        "source": "Input/ForeignKey.editable",
        "relation": {
            "repository": "MyRepositoryIdentifier"
        }
    }
}

Konzeptionell ist es gedacht, Layout und Inhalt an dieser Stelle zu trennen.

Layout spezifische Inhalte wie Ausrichtung, Formatierung, etc. sollten in den Einstellungen ($element→settings) gespeichert werden.

Inhaltliche Inhalte wie Texte, Silbentrennungen sollten eher in Quelldatensätze (->getEntity($elements→source)) gespeichert werden. Einer der Hintergründe ist hier Datenvermeidung. Falls in jedes PrintElement jedes Mal der gleiche Text geschrieben werden würde, zum Beispiel bei einem rechtlichen Hinweis der auf jeder Seite dargestellt werden muss, wären das viele Informationen in der Datenbank. In einem solchen Fall ist es dann besser, mit Quelldatensätzen für diesen Inhalt zu arbeiten.

Es ist möglich, eine Variatenauswahl für ein Element anzubieten. Damit kann man Varianten und Variantenkombinationen aus dem Styleguide einfach für das Element pflegbar machen. Dafür wird den Feldtyp Input/Select die source "PrintElementVariants" angeboten.

Um die Variantenauswahl für ein Element anzubieten, kann man in der StructureDefintion für den View ein Feld mit der source "PrintElementVariants" definieren. Dieses kann dann im Code für den Aufbau des Elements über die $settings abgerufen werden.

{
    "identifier": "variants",
    "label": "i18n:View/MyViewPackage.TranslationKey",
    "type": "Select",
    "configuration": {
        "multiple": true,
        "source": "PrintElementVariants",
        "print": {
            "plugin": "MyPackage",
			"view": "myview"
        }
    }
}

Um Varianten für die source PrintElementVariants zur Auswahl hinzuzufügen, kann das Event \Brandbox\PrintCore\PrintDocument\Structure\Lib\Event\OnPopulateVariants verwendet werden. Wichtig ist, dass man nur relevante Varianten für die Kombination aus $plugin und $view hinzufügt.

Für diese Vorgehensweise gibt es die Klasse \Brandbox\PrintCore\PrintDocument\Structure\Lib\Request\Listener\PrintDocumentStructure\PopulateVariants\PopulateVariantsAbstract von der abgeleitet werden kann. Damit kann man die Varianten über ein Array definieren.

use Brandbox\PrintCore\PrintDocument\Structure;

class Variants extends Structure\Lib\Request\Listener\PrintDocumentStructure\PopulateVariants\PopulateVariantsAbstract
{
    public const PLUGIN = 'View/PrintParagraph'; // Für welches Plugin soll diese Varianten dargestellt werden
    public const VIEW = 'paragraph';             // Für welchen View soll diese Varianten dargestellt werden
    public const VARIANTS = [                    // Die Varianten
        'MyKeyVariant1' => [                       // Interner Key um in der Eventstruktur die Variante identifizierbar zu machen
            'label' => 'i18n:View/MyPackage.EnumerationVariantsExampleOne', // Übersetzungskey für den Namen
            'variants' => ['specific', 'underline']                         // Variantenkombination 
        ],
        'MyKeyVariant2' => [
            'label' => 'i18n:View/MyPackage.EnumerationVariantsExampleTwo',
            'variants' => ['special']
        ]
    ];
}

Man sollte beachten, dass die erstellten Tabellen für die Views 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.

Mit \Brandbox\PrintCore\PrintDocument\Render\Lib\Struct\ElementHelperTrait steht ein Trait zur Verfügung, mit dem allgemeine Einstellungen verarbeitet werden können.

Damit kann das $element zum Beispiel um

  • Die Varianten aus den Einstellungen erweitert werden (wenn das Variantenfeld variants benannt wurde)

  • Die Print-Optionen wie Seitenumbrücke definiert werden

  • Bookmark Attribute erweitern

  • Inhaltsverzeichnis Attribute erweitern

  • Siehe auch Print-Features

Auch kann hiermit die Rückgabe als \Brandbox\PrintCore\PrintDocument\Render\Lib\Struct\ElementResultAbstract verkürzt werden.

use Brandbox\PrintCore\PrintDocument\Render;

class... {

	use Render\Lib\Struct\ElementHelperTrait;

	public function get(Render\Lib\Struct\ScopeElement $scope): Render\Lib\Struct\ElementResult
	{
	    $paragraph = new PrintStyleguide\Entity\PrintParagraph();
    	$paragraph->content = $this->getContent($scope->settings);

    	$this->populateDefault($paragraph, $scope);       

		return $this->elementResult($elements);  
    }
}

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

  • Keine Stichwörter