Nachhilfe bei Trennung von Code und Content

[ministry]

Moin,
hat jemand für mich bitte etwas Lektüre bezüglich Templatesystemen / Trennung von Code und Inhalt/Design?

Es geht für mich speziell darum, wieviel Logik ins Template gehört...

Z.B. bei einer Eingabeüberprüfung von einem Formular - erstelle ich bereits bei der Überprüfung einen Fehlerstring (was logischer und einfacher wäre - mir aber ja "Inhalt" auf die PHP-Seite bringt (d.h. zum Bleistift, ich kann nicht mehr "einfach" den ganzen Templateordner ins Englische übersetzen lassen))? Oder erstelle ich einen Fehlerindex und habe dafür im Template ein teilweise recht umfangreiches if - else gewurschtel?

Oder bei Eingabebestätigungen ("sind Sie sicher, dass dies und das jetzt so eingetragen werden soll?"). Soll die in ein Extra-Template? Oder soll man das doch lieber durch Schalter steuern {if $form_check_ok == 1} Sind sie sicher blabla {else} Formularzeug {/if} ?

Was mach ich mit Ausgaben, die ohne template ungefähr so entstehen würden:

$output = "Bitte bestätigen: einen Feiertag am " . $f_day . "." . $f_month . "." . $f_year . " für ";

if ($entry_type == 'all') $output .= " alle Mitarbeiter"; 
else if (count($nl) == 1) $output .= " eine Niederlassung"; 
else $output .= count($nl) . " Niederlassungen";

$output .= " eintragen"; 

Wird mit Logikschaltern im Template etwas kompliziert, oder?

[Shurakai]

Es geht für mich speziell darum, wieviel Logik ins Template gehört...

Das muss im Grunde genommen jeder selber entscheiden.


Ich persl. würde Language-Variablen einführen, die du dann je nach Bedarf lädst...

[ministry]

Hmm...

Naja - der Nachteil wäre natürlich, dass ich dann einen Haufen von solchen Satzfragmenten als language-Variablen im PHP-Code rumfliegen habe, die ich dann mit PHP zusammensetze und als z.B. $content an das Template übergebe (oder war es nicht so gemeint?).

Oder geht es anders? Wenn ich die Satzteile einzeln als language-Variablen anlege, die an das Template übergebe und dort zusammensetze, dann müssen doch die Templates trotzdem wegen Datumsformat und Satzstellung angepasst werden, und man hätte doppelte Arbeit beim Übersetzen?

[Slava]

die Fehlermeldungen, die bei falschen eingaben angezeigt werden gehören in die logische teil von Anwendung.
Du kannst if abfragen und schleifen bei deiner Layout-teil nicht vermeiden, egal, ob du es mit komischer Smarty-code oder mit php machst, aber die in Template vorkommende Code muss wirklich nur für die Layout sorgen.
also wenn du eine variable hast, die Fehlermeldungen drin hat, dann schaust du einfach in deiner Template teil, ob diese variable leer ist oder nicht.
wenn nicht leer, dann ein div aufmachen, und der Inhalt von Fehlermeldung rein packen.
wenn leer, dann machst du eben kein div.
also um eine Trennung zwischen Programm und Daten-beschaffungs-Logik
von Ausgabe-Logik zu schaffen, halte ich mich an folgende Regeln.

1)Programm und Datenbeschaffung-Logik
in dieser Teil untersuche ich die Eingabeparameter und treffe die Entscheidung, welche Daten ich liefern muss.
Ich beschaffe die Daten, und übergebe sie in Form von einfachen variablen, Objekten und Arrays an die Layout-script.

2)Layout-Logik- script(template)
benutzt die Daten, der er von Programmlogik bekommen hat, und formatiert die angekommene Daten für html, xml, pdf, bilder oder anderen ausgaben.
Dabei ist jede Art von schleifen, if-abfragen und anderen funktionen , die gewünschte Ausgabe erzeugt, gerechtfertigt.

die schone Vorstellung, dass man in einer Template die Code vermieden lässt, ist utopisch und kann sich nur bei ganz einfachen Seiten umsetzen.
Template-Systemen sind nicht für einer Trennung von php-code und html ausgedacht, sondern für Trennung von Programmlogik und Ausgabelogik

[ministry]

Okay... das ist ja schonmal eine Ansage. Trotzdem:

Original geschrieben von Slava
also wenn du eine variable hast, die Fehlermeldungen drin hat, dann schaust du einfach in deiner Template teil, ob diese variable leer ist oder nicht.
wenn nicht leer, dann ein div aufmachen, und der Inhalt von Fehlermeldung rein packen.
wenn leer, dann machst du eben kein div.

So einfach geht es dann ja nur bei Einsprachigkeit... wenn ich dem Übersetzer nicht den PHP-Code geben will, in dem die Fehlermeldungen erzeugt werden, sondern eben nur die Templates, dann muss ich doch anhand eines Fehlercodes im Template unterscheiden, was in dem Fehlerdiv nun drinsteht...

Aber das lässt sich anscheinend nicht so einfach vermeiden. Ich danke dir, hab jetzt schonmal eine bessere Vorstellung, worauf es hinausläuft.

[Slava]

Original geschrieben von ministry
So einfach geht es dann ja nur bei Einsprachigkeit... wenn ich dem Übersetzer nicht den PHP-Code geben will, ....

natürlich nicht.
du muss dem Übersetzer nur die fehlermeldungen in einer Sprachen geben, die er in die andere übersetzt.
Aber die Entscheidung, in welcher Sprache eine fehlercode kommt wirst natürlich nicht in Template, sondern in deiner Daten-Beschaffungs- Teil machen. Die Template sorgt nur für die formatierte Ausgabe und nicht für die Feststellung von Benutzer-Sprache.
Also in Template nur die vorbereitete Daten zur Ausgabe bringen, und wenn das sein muss, dann benutze dafür alle functionen und steuerung-strukturen, die du nur kennst.

bei einer mehrsprachiger seite müssen natürlich auch mehrere Bezeichner , aus dennen die Ausgabe besteht vorhanden sein, und das kann auch ein wenig unübersichtlich werden. deshalb wäre es nicht schlecht, wenn du dokumentation machst, und beschreibst kurz alle variablen, die an dein Layout-script übergeben werden. Das alles verlangt natürlich mehr Aufwand, aber wenn du Morgen statt einem html-Document eine PDF datei ausgeben möchtest, dann muss du nicht mehr in deine Programm-Logik angreifen, sondern nur eine neuer Ausgabe-script zu schreiben, in dem du einfach die gewohnene Daten formatierst.

[ministry]

du muss dem Übersetzer nur die fehlermeldungen in einer Sprachen geben, die er in die andere übersetzt.
Aber die Entscheidung, in welcher Sprache eine fehlercode kommt wirst natürlich nicht in Template, sondern in deiner Daten-Beschaffungs- Teil machen. Die Template sorgt nur für die formatierte Ausgabe und nicht für die Feststellung von Benutzer-Sprache.
Also in Template nur die vorbereitete Daten zur Ausgabe bringen, und wenn das sein muss, dann benutze dafür alle functionen und steuerung-strukturen, die du nur kennst.

Das ist mir klar... die Idee war allerdings, auf eingebundene Sprachdateien bzw. irgendwelche Datenbanklösungen zu verzichten, und stattdessen den ganzen Templateordner (und sonst nichts) beim Übersetzer abzugeben. Je nach gewählter Sprache änder ich dann nur den Pfad zum Templateordner.

Daher muss die Unterscheidung, welcher Fehler aufgetreten ist, im Template erfolgen, weil *alle* Texte in den Templates stehen müssen. Also übergebe ich eine Fehlerid und hab im Template ein mittelgroßes Gewirr von {if $errorid == 1} Fehler nummer 1 ist aufgetreten{else if ...}usw.

Damit kann ich allerdings besser leben als mit allen $lang-.. Lösungen.

[PHP-Desaster]

Fehlermeldungen oder Meldungen generell packe ich mir immer in ein Objekt, welches je nach sprache mit anderen Texten geladen wird! Im Code hast du dann sowas wie:

if( wrongPassword() ) {
     $template->addError( ErrorMessages::WRONG_PASSWORD );
} 

Das Objekt mit den Meldungen hat jetzt im Beispiel alle Meldungen als Konstanten gekapselt. Du initialisierst dir diese Klasse dann so:

include "messages.".$language.".const.php"; 

So hast du Logik und Ausgabe absolut voneinander getrennt!!

[ministry]

Die Idee finde ich gar nicht so schlecht - dann muss eben neben den Templates auch noch die Liste der Konstanten für diese Klasse mitübersetzt werden.

Die, wie soll ich sagen, aktionsbezogenen Sachen stehen dann in den Templates und Fehlermeldungen und Phrasen die öfter auftauchen, können in diese Klasse.
Das praktische ist, dass man alles nach und nach umbauen kann...

Das werd ich wohl einbauen denk ich, danke!