Multilinguale Beschriftungen über View oder direkt über HTML

[MB]

moin,

was gibt es für pros / cons wenn man in einem MVC Framework die Beschriftungs-Daten wie "Benutzer, "Passwort" über die Klasse View einbindet new View( $data, $path, $lang )? Ein Beispiel:

<form>
  <label><?=$lang[ 'form_user' ]; ?></label>
  <input type="text" id="user" />
</form>

Was für vorteile bringt es wenn man die Beschriftung mit beispielsweise Traits direkt in der HTML übergibt? Ein Beispiel:

<form>
  <label><?=__( 'form_user' ); ?></label>
  <input type="text" id="user"/>
</form>

lgmb

[dedlfix]

Tach!

was gibt es für pros / cons wenn man in einem MVC Framework die Beschriftungs-Daten wie "Benutzer, "Passwort" über die Klasse View einbindet new View( $data, $path, $lang )?

Was ist denn deine Antwort auf diese Frage? Wer instantiiert denn diese View? Ist es der Controller, der dann neben den fachlichen Dinge auch noch die Daten für $lang beschaffen muss?

Was für vorteile bringt es wenn man die Beschriftung mit beispielsweise Traits direkt in der HTML übergibt?

Vorteile gegenüber welcher anderen Vorgehensweise? Ohne Traits würde man vielleicht einen Service einbinden, der die sprachspezifischen Texte liefert. Das nimmt sich nicht viel in der Anwendung.

dedlfix.

[MB]

moin,

was gibt es für pros / cons wenn man in einem MVC Framework die Beschriftungs-Daten wie "Benutzer, "Passwort" über die Klasse View einbindet new View( $data, $path, $lang )?

Was ist denn deine Antwort auf diese Frage? Wer instantiiert denn diese View? Ist es der Controller, der dann neben den fachlichen Dinge auch noch die Daten für $lang beschaffen muss?

In meiner App habe ich nur eine Klasse View die instanziirt wird und die dann die Daten von dem Parent Controller nimmt.

Was für vorteile bringt es wenn man die Beschriftung mit beispielsweise Traits direkt in der HTML übergibt?

Vorteile gegenüber welcher anderen Vorgehensweise? Ohne Traits würde man vielleicht einen Service einbinden, der die sprachspezifischen Texte liefert. Das nimmt sich nicht viel in der Anwendung.

Hab ich doch beschrieben.

• Trait auf der Namespace-Oberfläche also nicht System\Core\Lang::__( 'user' ); sondern eben nur __( 'user' ); eben ohne Namespace
• View mit Sprache als zusätzlichen Parameter: new View ( [ 'user' => 'MB' ], 'view/layout.html', System\Core\Lang::__( 'user' ) );

[MB]

moin,

Vorteile gegenüber welcher anderen Vorgehensweise? Ohne Traits würde man vielleicht einen Service einbinden, der die sprachspezifischen Texte liefert. Das nimmt sich nicht viel in der Anwendung.

Sorry, mein Fehler, ich hab was vergessen. Ich hab den ersten Punkt das fälschlicherweise mit den Traits erwähnt.

• Trait auf der Namespace-Oberfläche also nicht System\Core\Lang::__( 'user' ); sondern eben nur __( 'user' ); eben ohne Namespace

Das 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. Bitte entschuldige das Missverständnis das durch meine erläuterde Vorhergehensweise hervorgegangen ist.

lgmb

[dedlfix]

Tach!

• Trait auf der Namespace-Oberfläche also nicht System\Core\Lang::__( 'user' ); sondern eben nur __( 'user' ); eben ohne Namespace

Das 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.

[MB]

moin,

Ok, Besten Danke für die Erläuterung.

lgmb