Guideline zur Erstellung von Tibi-Projekten

Dieses Dokument beschreibt den Prozess vom fertigen Webdesign zum Tibi-Projekt. Die Methodik Top-Down-Modellierung findet hier Anwendung.

Ausgangspunkt

der Designentwurf für das Frontend liegt vor
die benötigten Datenstrukturen sind klar
- evtl. dazu innerhalb der Konzeptphase gemeinsam Datenstruktur erarbeiten

anhand der benötigten Datenstrukturen Kollektionen formen
ohne direkt in Tibi-Konfigs zu starten am besten die Kollektionen mit anderen Tools visualisieren und Abhängigkeiten erkennen un einzeichnen (Entity Relation)
beim Entwickeln der Kollektionen unterschiedliche Berechtigungen berücksichtigen
- z.B. Kollektion für Einstellungen von Modulen müssen normale Redakteure nicht bearbeiten, echte Inhalte dagegen schon
Anzahl der Kollektionen gering halten, da
- viele Verknüpfungen mehrere Anfragen im tibi-server benötigen (Performance)
- Datensätze verteilt auf mehrere Kollektionen dem Benutzer mehr Klicks abverlangen (Usability)
- mongoDB im Gegensatz zu relationalen Datenbanken sehr gut mit eingebetteten Daten innerhalb von Objekt-Strukturen zurecht kommt
jedoch, Daten auf nötige Kollektionen aufteilen um Backend-Masken nicht zu überladen

Einteilung der Datenfelder in Gruppen
- Meta-Daten (sind also nicht direkt sichtbar -> SEO oder Zusatzinformationen)
- Daten die Überblick schaffen (Titel, Teaser-Text)
- allgemeiner Inhalt (Detailtext)
- spezifischer Inhalt (Datum, Uhrzeit bei z.B. Veranstaltungen)

Navigation als eigene Kollektion
Inhalte der Website alle zusammen in ein Kollektion, da
- über Pfad ansprechbar, welcher als Feld innerhalb der Kollektion gespeichert wird und somit beim Aufruf nur 1 eine Kollektion durchsucht werden muss
- viele Felder wiederverwendet werden über verschiedene Inhaltstypen (z.B. Meta-Titel, Keywords, Veröffentlichungsdatum)
Inhalte-Kollektion kann unterschiedliche Arten von Inhalten trennen durch
- Typ-Feld
- Verwendung der Unternavigationsfunktion mit Vorfilterung des Types, dabei kann ebenso das Tabellenlayout je Inhaltstyp definiert werden
Mediathek-Kollektion als Sammelbecken für alle Uploads
- Dateien können kann über Foreign-Key-Beziehung in anderen Kollektionen verknüpft und wiederverwendet werden
Module-Kollektion zur Verwaltung der Einstellungen benötigter Frontend-Module, z.B.
- ein Modul kann z.B. eine Teaser-Liste des Inhaltstyps "News" sein, welcher in der Inhalte-Kollektion gespeichert ist
- Einstellungen zu einem Modul könnten z.B. Filterkriterien und die Sortierung für das Listing sein

Festlegen was statische Template-Elemente sind und was Module sind, die in Seiteninhalten wiederverwendet werden können
Einteilen der Module nach Typen, z.B.
- Mitarbeiterliste
- News-Teaser-Liste
zu den jeweiligen Modulen Ausprägungen und die damit verbunden Einstellmöglichkeiten festhalten, z.B.
- Anzahl der Einträge in einer Liste
- Darstellungsart der Liste
- Filterung der Einträge
- Sortierung der Einträge

Kollektionen und Feld-Gruppen geben groben Rahmen vor
Aufteilung der Feldgruppen in Tabs oder Sektionen
Ein-/Ausblenden von Feldern in Abhängigkeit anderer Eingaben, wie z.B. Typ des Inhalts (News blendet Datum ein)
hierbei sollte der Projektleiter, der die Kunden-nähe hat, unbedingt unterstützen

Einhaltung der Ordnerstruktur api/ laut tibi-docs
Aufteilung thematisch passende YAML-Dateien der Projekt-Konfig
- config.yml als Einstieg
- jede Kollektion hat eigene Datei
- Auslagern von größeren Datenstrukturen in eigene Dateien zur Wahrung der Übersicht
- Auslagern von Feld-Konfigurationen, wenn diese kollektionsübergreifend mehrfach verwendet werden
Verwendung von aussagekräftigen Feldnamen
- möglichst englische Namen
- camelCase Schreibweise
benutzerfreundliche Label in deutsch und optional englisch
falls nötig eine kurze Beschreibung für die UI, was bei diesem Feld wichtig ist oder wie es funktioniert, bzw. wo es Verwendung findet, wenn dies nicht automatisch klar seien sollte
Verwendung des Validators
- Pflichtfelder kennzeichnen
- Inhalt validieren um keine bösen Überaschungen auf der Website zu erleben (JS-Fehler, weil undefined)

!!! Weniger ist mehr. Komplexe Strukturen so einfach wie möglich dem Benutzer aufbereiten !!!

Inhalte, die so gut wie nie angepasst werden, müssen nicht ins Backend, z.B.
- Designelemente wie Logo, Farben
Template-Bestandteile, die den Redakteur nix angehen, gehören auch nicht ins Backend, z.B.
- CSS, JS
einmalig vorkommende Elemente können als Module zur Verfügung gestellt werden, müssen aber keine weiteren Daten im Backend haben, d.h.
- ein Eintrag in der Modul-Kollektion, aber keine weiteren Einstellungen
- können vom Redakteur in Inhalten zugeordnet werden
- binden im Frontend nur einen statischen Code-Block ein, z.B.
  - komplexe Grafik/Animation, welche im Frontend eine Programmierung benötigt