Extbase: Model-Zugriff in Validatoren

Für den Fall, dass die Standard-Validatoren von Extbase oder benutzerdefinierte Validatoren für einzelne Eigenschaften eines Models nicht genügen, gibt es noch die Option eines benutzerdefinierten Validators mit vollem Zugriff auf die neue Instanz eines Models.

Dafür kann man sich eine gänzlich undokumentierte Feinheit des Extbase-Frameworks zunutze machen: standardmäßig wird in einem Standardpfad versucht, einen passenden Validator passend zu einem Model zu finden. Wieder ein Beispiel für „Konvention über Konfiguration“, worauf in Extbase und FLOW3 Wert gelegt wird.

Der besagte Validator wird standardmäßig unter Classes/Domain/Validator/ModelNameValidator.php gesucht. Wie bei allen Extbase-Validatoren üblich ist zur Erfüllung der Schnittstelle Tx_Extbase_Validation_Validator_ValidatorInterface (OOP-Konvention wäre hier eigentlich IValidator) eine Ableitung von Tx_Extbase_Validation_Validator_AbstractValidator empfehlenswert. Dessen isValid-Methode erhält als einziges Argument die betreffende Instanz des Models, womit dann beliebige Überprüfungen vorgenommen werden können. Da hier ein uneingeschränkter Zugriff auf alle Eigenschaften des Models gegeben ist, können so auch komplexe Validierungen mit Abhängigkeiten zwischen Eigenschaften und dergleichen vorgenommen werden.

Der Validator sollte zu guter Letzt wie immer true oder false zurückgeben um über das Ergebnis der Validierung zu informieren und im Fehlerfall zuvor noch eine aussagekräftige Fehlermeldung vermerken. Dies kann entweder über die addError-Methode oder direkt per Manipulation der errors-Eigenschaft geschehen:

// 1) addError()
$this->addError('Descriptive error message', 0000000000); // Hier sollte 0000000000 eine eindeutige Nummer sein
 
// 2) errors
$this->errors[] = new Tx_Extbase_Validation_Error('Descriptive error message', 0000000000); // Siehe oben

Letztere Variante bietet die Möglichkeit, manuell Instanzen von Tx_Extbase_Validation_PropertyError einzufügen. Dadurch können bestehende, auf Model-Eigenschaften optimierte, Partials für die Ausgabe von Validierungsfehlern ohne Anpassung verwendet werden. Dazu hängt man die eigentlichen Fehlermeldungen an eine Fake-Eigenschaft:

// Container für gruppierte Fehlermeldungen über eine Fake-Eigenschaft anlegen
if (!isset($this->errors['fakeProperty']) {
 
  $this->errors['fakeProperty'] = new Tx_Extbase_Validation_PropertyError('fakeProperty');
}
 
// Eigentliche Fehlermeldungen an den Container anhängen
$this->errors['fakeProperty']->addErrors(array(
  new Tx_Extbase_Validation_Error('Descriptive error message', 0000000000); // See above
));

Da dieser Validator allgemein für das Model gilt, wird er immer dann zur Rate gezogen, wenn eine neue Instanz des Models im Zuge einer Aktion angelegt werden soll. Wahlweise kann man dies allerdings auch manuell für die gewünschten Aktionen eines Controllers über die  @validate …Validator.php DocComment-Notation erfolgen. Allerdings sollte man dann darauf achten, dass der Validator nicht der oben beschriebenen Pfad-Konvention folgt. Andernfalls wird der Validator wie gehabt immer aufgerufen, @dontvalidate einmal ausgenommen. Auf diese Weise können der Zielaktion auch beliebige weitere Validatoren hinzugefügt werden, welche jeweils den gleichen Zugriff auf das Model haben.

Mingetty und systemd

Das von systemd standardmäßig für das Öffnen virtueller Terminals genutzte agetty verfügt verglichen mit mingetty nur über einen sehr beschränkten Funktionsumfang. So ist gerade die Option --autologin von mingetty interessant, wenn man beim Start des Systems automatisch einen Nutzer ohne manuelle Eingaben anmelden möchte. Unter SysVinit ist hierfür folgender Eintrag in der /etc/inittab erforderlich:

1:2345:respawn:/sbin/mingetty --autologin USER tty1

Die Konfiguration unter systemd gestaltet sich dagegen komplett anders, ermöglicht aber eine nicht minder flexible Anpassung:

  1. Die Datei /lib/systemd/system/getty@.service nach /etc/systemd/system kopieren
  2. Die Datei /etc/systemd/system/getty@.service editieren und in der Sektion [Service] die Option ExecStartwie folgt ändern:
    ExecStart=-/sbin/mingetty --autologin USER %I
  3. Ändern des Standard-Symlinks für die Startdefinition des getty-Dienstes auf tty1 (analog für die anderen virtuellen Terminals):
    ln -sf /etc/systemd/system/getty@.service \
    /etc/systemd/system/getty.target.wants/getty@tty1.service

    Dieses Kommando muss auch nach jedem Update von systemd ausgeführt werden, da dies die Dateien in /etc/systemd neu generiert.

Hiernach kann der Dienst neu gestartet werden. Eine laufende X-Sitzung wird damit allerings auch beendet:

systemctl restart getty@tty1.service

Ab diesem Zeitpunkt wird bei jedem Systemstart der per USER spezifierte Nutzer automatisch angemeldet. Als kleiner Bonus noch eine mögliche Vorgehensweise, um dabei auch automatisch den X-Server zu starten:

if [ -z "$DISPLAY" -a $(tty) = /dev/tty1 ]; then
  startx
fi

Hier wird geprüft, ob noch kein X-Server gestartet wurde (die Umgebungsvariable $DISPLAY ist andernfalls gesetzt) und ob wir uns gerade auf tty1 befinden, von wo aus üblicherweise der erste X-Server gestartet wird. Einzutragen ist das ganze in die ~/.bash_profile, nicht in die ~/.bashrc.