Tach!
- Trait auf der Namespace-Oberfläche also nicht
System\Core\Lang::__( 'user' );
sondern eben nur__( 'user' );
eben ohne NamespaceDas ist von mir aus nicht korrekt. Auf der Namespace-Oberfläche ist eine funktion ...
public function __( $key ) { return \System\Core\Lang::get( $key ) }
... die dann im HTML-Code auf gerufen wird.
Das ist ja nur eine Komfortfunktion. Die ist aber nicht der entscheidende Teil an der Lösung. Ein Trait ist eine Hinzufügung von Code zu einer bestehenden Klasse. Die Frage ist aber, warum soll der View ein Stück Code hinzugefügt werden? Kann man nicht diese Funktionalität bekommen, indem man einen Service befragt? Man muss dann nicht aufpassen, dass der Trait zur View passt. Ein Service ist eine Komponenten für sich, und der kann im Inneren schalten und walten, wie es ihm beliebt. Nach außen stellt er seine Dienste über eine definierten API zur Verfügung, in dem Fall eine Methode, die man aufruft und zum übergebenen Text die Übersetzung zurückbekommt.
Ob ich nun den Service befrage oder eine Funktion aufrufe oder eine Methode, die direkt oder per Trait an der View-Klasse hängt, bringt im Handling keinen großen Unterschied. Man hat da ja nicht viel Spielraum für die Aufgabe: "Gib mir einen Text für einen Text, den ich dir gebe." Was man am Ende nimmt, ist also eher eine Frage, für welche Architektur man sich entscheidet.
dedlfix.