2. NodeTypes

Ein wenig Theorie bevor wir durchstarten. Inhalte in Neos sind werden in sogenannten Nodes gespeichert. Das können unter anderem Seiten, Medien, Text, Headlines, Formulare, Buttons, Menüs oder Links sein. The sky is the limit.

Nodes können andere Nodes in sich halten. Dadurch, dass Nodes verschachtelt sein können, werden sie in einer Art Baumstruktur gespeichert (Stichworte Document- und Content Tree). Dieser Baum aus Nodes ist die Content-Repository. Der Vorteil dieses Baumes liegt darin, dass er einfach zu durchlaufen ist, sodass die beinhalteten Nodes wo anders abgerufen und wiederverwendet werden können. Die verschiedenen Arten von Nodes (Medien, Text etc.) werden NodeTypes genannt und müssen selbst gebaut oder aus Packages installiert werden.

So weit so gut. Nur was hat das zu bedeuten? Grundsätzlich lässt sich sowas in den Neos Docs nachschlagen, wir können aber trotzdem einmal über die Zeilen drüber gehen.

1. NeosTutorial.Site:Content.Banner ist der Name des NodeTypes. Es wird als best practice angesehen, NodeTypes nach diesem Namensschema zu benennen: <PackageName>:<Prefix>.<Name>. Als <Prefix> soll aus “Document", "Content", "Mixin", "Collection" oder "Constraint" gewählt werden. In diesem Fall bauen wir ein Inhaltselement und wählen den Präfix “Content”.
2. superTypes ist ein Array, in dem Eltern-NodeTypes angegeben werden. Dessen NodeType-Konfiguration wird auf unsere übertragen.
3. Weil wir einen Content-NodeType erstellen, wählen wir den SuperType Neos.Neos:Content (es ist auch möglich die Vererbung einzelner NodeTypes abzuschalten, indem ein FALSE angegeben wird).
4. Unter ui geben wir an wie der NodeType in der NodeType-Auswahl im Backend angezeigt werden soll.
5. label ist der Anzeigename
6. group gibt an wo der NodeType eingeordnet wird. ‘general’ ist eine vordefinierte Gruppe. Neue eigene Gruppen können in einer Settings.yaml definiert werden.
7. icon gibt das Icon an, welches in der Auswahl verwendet wird. Der Wert beginnt immer mit ‘icon-’. Die Icons werden aus FontAwesome genommen.
8. Unter properties werden die Eigenschaften unseres NodeTypes definiert. Diese Eigenschaften werden vom Benutzer selbst gesetzt.
9. text ist der Name unserer ersten Property.
10. Unter type gibt man die Art der Property an. In diesem Fall nehmen wir “string”. Je nach Typ erhält man einen passenden Editor zum setzen der Properties. Mit dem Typ “string” können wir den Inhalt direkt in der Vorschau setzen. Welche Types man angeben kann steht in der PropertyEditorReference.
11. Der defaultValue wird gesetzt, wenn die NodeType frisch erstellt wurde. Den Wert anzugeben gehört auch zu den best practices, da jeder neu erstellte NodeType valide sein muss.
12. Properties werden im Backend im Inspektor (rechte Seite im Backend) gesetzt. Unter ui gibt man an wie die Eingabefelder im Inspektor angezeigt werden.
13. Da wir diese Property aber direkt im Dokument editieren wollen geben wir inlineEditable: TRUE an, wodurch im Inspektor nichts eingestellt werden muss.

Laden wir das Backend neu und klicken im “Create New”-Fenster nun auf unseren neuen NodeType, bekommen wir einen netten Fehler.

Wir müssen nämlich die eigentliche Logik des NodeTypes noch bauen. Das ist der Fusion-Teil.

Hier lohnt es sich vorher schlau zu machen was Fusion ist und wie es funktioniert. Darum wird es im nächsten Kapitel gehen.

Um uns in Zukunft Arbeit zu ersparen, können wir Standard-NodeTypes, von denen wir immer erben erweitern bzw. überschreiben. 

Davon möchten auch wir auch gebrauch machen und eine neue Inspektor-Gruppe erstellen, wo unsere eigenen NodeType-Properties platziert werden können.

In der Regel erben wir fast immer von Neos.Neos:Content, also erweitern wir diesen NodeType. Dafür wird die Datei NodeTypes.yaml erstellt und mit dem Code gefüllt:

• Mehr Details zu NodeType-Definitionen und der Content-Repository in den Neos Docs