Sprachvariablen in smarty

[dowhile]

Die ganzen IF-Bedingungen und die Escape-Funktionen gehören nicht in nen View

Wieso nicht?

Views im MVC-Modell sind die Komponenten, die für die Darstellung des Modells verantwortlich sind. Die Darstellungsarten sind dabei nicht eingeschränkt. Grundsätzlich könnte ein View die Daten des Modells auch durch die Nutzung eines Sprachgenerierungsmoduls vorlesen. Allerdings erscheint für diesen Fall die Bezeichnung View nicht mehr völlig adäquat.

Views sollten sich ausschließlich mit der Darstellung beschäftigen und möglichst keine fachliche Logik enthalten. Allerdings werden in einigen Fällen Funktionen des Controllers mit im View integriert.

( )

Genau das wird doch damit erfüllt. Es liegen irgendwelche Daten vor und diese werden so aufbereitet, dass sie ordentlich angezeigt werden.
Es liegt ein Array mit 20 Einträgen vor, die dem Benutzer angezeigt werden sollen. Wieso sollte es nicht Aufgabe des Views sein, aus diesem Array mit 20 Einträgen HTML Code für eine Liste zu generieren?
Angenommen das Array enthält zwischen 0 und 20 Einträgen. Wieso darf das View nicht entscheiden, dass es statt einer leeren Liste eine Nachricht anzeigt, wenn 0 Einträge vorhanden sind? Es wird dabei keine Logik geschrieben, die das Verhalten der Anwendung beeinflussen würde, sondern nur Logik zur richtigen Darstellung der Daten.

Kannst du begründen, weswegen das nun entgegen meiner Auffassung nicht in den Zuständigkeitsbereich der Präsentation fällt?

Dieses Beispiel kann keine TPL Engine der Welt schlagen (ja ich habs so nachgebaut wie es oben steht, ich weiß nicht wo seine IF-Abfrage geblieben ist!)

else funktioniert in Verbindung mit foreach? Wusste ich noch nicht. Auf der php.net Seite zu foreach / zu else wird das aber auch nicht erwähnt. Fehlt das da?

Für jemanden, der kein PHP und auch sonst keine Programmiersprache kann finde ich die Twig Syntax für das Problem aber weiterhin schöner bzw. einfacher.

Aber ich verstehe den Sinn noch immer nicht. Der nutzen in den Template Enginen liegt doch darin, Logik und Ausgabe zu trennen und trotzdem nutzen es genau alle zu dem Zweck.. S:

Die Präsentation soll von der Logik getrennt werden, die die Anwendung "steuert" (also im Sinne von der Geschäftslogik). Die Logik, die du bei Twig / Smarty / ... antriffst ist aber nur für die Darstellung der Daten zuständig. Sie steuert nichts im Sinne von "wenn das Array leer ist, schicke ich noch eine E-Mail an X und lösche die Datenbank" sondern befasst sich eben rein damit, was dem Benutzer angezeigt wird, wenn das Array (nicht) leer ist. Sie bringt die Daten in eine Form, wie sie der Endnutzer komfortabel einsehen kann. Ich ging seither davon aus, dass genau das die Aufgabe der Präsentation / des Views ist (und in Symfony 2 und dem APF wird das auch genau so umgesetzt) und daher völlig im Sinne von MVC.
Zumindest dann, wenn nur MVC genutzt wird, und die Anwendung nicht "zusätzlich" nach dem Schichtenmodell unterteilt wird.

[Synatex]

Es liegt ein Array mit 20 Einträgen vor, die dem Benutzer angezeigt werden sollen. Wieso sollte es nicht Aufgabe des Views sein, aus diesem Array mit 20 Einträgen HTML Code für eine Liste zu generieren?

Warum nicht Aufgabe sein soll? Weil der nichts generieren soll. Gegenfrage, warum sollte man es nicht in den Controller auslagern, der im Normalfall eh Klassen dafür bereitstellt um diverse Sachen (bei eventuellen Fehlern o.Ä. direkt zu interpretieren?). Warum sollte man dem Controller nicht die Sache überlassen, aus dem ganzen das zu machen was es sein soll, und dem View wirklich nur das zuweisen was er ausgeben soll ? Obs nun 5 oder 10 Menüpunkte aus einem Array sind hat den nun mal nichts anzugehen aus meiner Sicht.

Kannst du begründen, weswegen das nun entgegen meiner Auffassung nicht in den Zuständigkeitsbereich der Präsentation fällt?

Die Antwort liefert dir einmal das Bild von der oben gezeigten Seite sowie ein Zitat aus dem Text:



Es würden hier bestimmt Funktionen wie aktualisiereWennNeueNachricht() oder aktualisiereWennMehrAlsEinBenutzer() beschrieben werden, wenn man wirklich nach deinem Prinzip gehen würde und den View danach zu bauen, welche Daten reinkommen. Aber da auch die Ausgabe (egal welche du nutzt, und ob du nur Links für irgendeine Website setzt) in Zusammenhang mit der Logik steht, ist das völlig irrelevant. Gehen wir mal davon aus du übergibst nicht nur Links, sondern Link-Objekte, die dann die hrefs, targets, alt-attribute und title haben. Diese sind dann in nem Array durcheinander gewürfelt und sollen alphabetisch geordnet werden. Wahrscheinlich würdest du dann auch noch irgendeine Funktion haben die das ganze im View sortiert, aber dass ist ja nicht der Sinn.

und deine selbst ernannte Antwort:

Views sollten sich ausschließlich mit der Darstellung beschäftigen und möglichst keine fachliche Logik enthalten. Allerdings werden in einigen Fällen Funktionen des Controllers mit im View integriert.

Erst Recht die Erzeugung des Quellcodes, also das wirkliche eingreifen in die Darstellung beim Nutzer, sollte ausgelagert werden. => Warum? Was ist denn, wenn der Controller sich entscheidet, Daten anders zu senden? Richtig, du darfst den View umbauen. Warum sollte man sich 2 Baustellen machen?

... antriffst ist aber nur für die Darstellung der Daten zuständig.

Der View sollte im besten Fall nie wissen was der Controller zurückgibt da dieses dumme Fenster dann nur zum ausgeben da ist. Eben das er möglichst universell einsetzbar ist und auf jedes Modell schnell angepasst werden kann.


Zuletzt ein ganz banales beispiel: Gehen wir einfach davon aus, dass wir 2 Controller haben? Controller 1 ist für Benutzereingaben Validierung verantwortlich und Controller 2 für die Verarbeitung. Beide Controller haben aber die Möglichkeit auf den View zuzugreifen der beispielsweise einen Fehler ausgibt. Controller 1 gibt Fehler als String zurück. Controller 2 als Array. Soll dafür jetzt auch noch eine Prüfung gebaut werden?

Man brauch darüber aber auch gar nicht diskutieren. Jeder wird seine eigene Meinung haben und diese so umsetzen so wie er oder sie es will. Meine ist nun mal, dass wenn ich so ein Konzept verwende, ich nicht noch eine unnötige Template Engine mit an Board hole die mir noch mehr Ressourcen zieht.

[Hiris]

Originally Posted by dowhile

Eine Template-Engine kümmert sich nur um die Darstellung ... Ist das nicht die Aufgabe der Präsentationsschicht?

Ich weiß nicht, wie genau Smarty funktioniert, aber bei Twig macht das IMHO schon einen Unterschied.







(Ich habe keine Ahnung von den alternativen Schreibweisen von PHP)

Ich finde die Syntax von Twig definitiv schöner und einfacher. Zudem gibt es noch Funktionen wie das Inkludieren anderer Templates, Wiederverwendung (mit Überschreibung) von Blöcken in einem Template, ...
Mit dem MVC Pattern ist das alles, denke ich, trotzdem noch gut vereinbar. Das sind schließlich alles Funktionen, die nur die Darstellung der Daten steuern.

Ooooooddddeeerrr man öffnet nicht 30 php Tags und macht einfach schönen sauberen PhP Code der gut eingerückt ist und den jeder in 2 Sekunden versteht ohne sich mit der Template Engine auszukennen, außerdem ist der Quellcode der Templatet engine das wiederlichste was mir bis jetzt untergekommen ist, aber das ist geschmackssache^^

[Phillor]

Was genau, könnt ihr mir denn statt smarty empfehlen?

, wo ich PHP hauptsächlich gelernt habe, wird auch erklärt, dass PHP bereits eine Template Engine ist und wie man ein eigenes Template System programmiert.

Und das habe ich auch noch über google gefunden. Ich bin mir da nicht so sicher, da es schon etwas älter ist...

[Synatex]

Die Frage ist: Brauchst du eine? Eine Template Engine macht an sich auch nur Sinn wenn das Dingen nachher public werden soll und du es weitervermarkten willst. Denn der Sinn dahinter ist ja, dass auch Designer sich ohne Probleme zurechtfinden. Wenn du also dein Projekt eh nur für die privat haben willst, dann machs doch einfach ohne, benutz die Short-Tags von PHP und sei glücklich das du nicht hunderte von Dateien extra mit in dein Projekt ziehst!

[Phillor]

Ich habe zwar nicht vor es zu veröffentlichen, aber später solle evtl noch 1-2 weitere Programmierer an dem projekt mitarbeiten und da wär eine gute Übersicht schon von Vorteil. Ich nur jetzt verunsicher, ob ich smarty weiterhin benutzen soll, da die seite ja bis jetzt über smarty läuft (obwohl ich mich eigentlich so nie richtig mit smarty anfreunden konnte) oder ob ich so n kleines Template System verwenden soll.
Denn die bessere Übersicht ist mir schon wichtig bei diesem Projekt.

[Synatex]

Dich hindert nichts daran, PHP an sich als Templatesystem zu nutzen! Wenn du Struktur reinbringen willst und noch nicht so weit fortgeschritten bist, ist dies eventuell ein gutes Beispiel für dich:

templates/fehler.php
(Fehlerausgabe Seite)

<html>
...
<body>
<h1>Fehler</h1>
<p><?=$nachricht;?></p>
</body>
</html>

templates/formular.php
(Würde dem Formular Template entsprechen!)

<html>
...
 <form action="../core/form.php" method="post">
   <input type="text" name="test">
   <input type="submit">
 </form>
...
</html>

core/formular.php
(Würde der Verarbeitungsdatei entsprechen)

PHP Code:

<?php
 $form = array();

 foreach($_POST as $key => $val) {
   $form[$key] = htmlspecialchars($val);
 }

 if($form['test'] == 'hallo') {
  // Mach was
  $nachricht = 'Fehler';
  $template = 'fehler';
 } else {
  // Mach was anderes
  $nachricht = 'Erfolgreich';
  $template = 'erfolgreich';
}

 include 'templates/'.$template.'.php';

?>

Ist nur nen Beispiel. Hab mich mit Template-Engine Alternativen nur bedingt ausseinandergesetzt.

[dowhile]

Originally Posted by Synatex

Warum nicht Aufgabe sein soll? Weil der nichts generieren soll.

Das heißt, dass das View zwar für die Darstellung der Daten verantwortlich ist, diese Darstellung aber nicht selbst generieren darf?
Ein Array soll als HTML Liste dargestellt werden, das View darf aber aus einem Array keine HTML Liste erstellen?

Sinn von MVC ist es doch, Model View und Controller zu trennen, um einzelne Teile austauschen zu können, ohne dabei die anderen modifizieren zu müssen. Das heißt, dass MVC zum Beispiel folgenden fiktiven Fall ideal abdeckt:

Eine Anwendung gibt eine Benutzerliste als HTML Code aus, damit sie im Browser betrachtet werden soll. Nach einer Änderung muss die Liste zusätzlich im JSON Format ausgegeben werden, um eine API für andere Anwendungen zu schaffen.

Wenn ich deine Auffassung richtig verstanden habe, müsste für diese Änderung sowohl Controller als auch View geändert werden, obwohl sich einzig und allein die Darstellung der Daten ändert. Man müsste im Controller immer unterscheiden, ob die Liste aus dem Array mit HTML Tags oder mit JSON Syntax generiert werden muss. Zusätzlich müssen verschiedene Views verwendet werden, denn das alte könnte über der Liste beispielsweise noch eine Überschrift mit HTML ausgeben.
Wird das komplette Markup im View generiert, müsste nur ein zusätzliches View erstellt werden; am Controller müssen keine Änderungen vorgenommen werden (außer dass das richtige View gewählt wird).

Gegenfrage, warum sollte man es nicht in den Controller auslagern, der im Normalfall eh Klassen dafür bereitstellt um diverse Sachen (bei eventuellen Fehlern o.Ä. direkt zu interpretieren?).

Das verstehe ich nicht.

Warum sollte man dem Controller nicht die Sache überlassen, aus dem ganzen das zu machen was es sein soll, und dem View wirklich nur das zuweisen was er ausgeben soll ?

Weil es dem Controller egal sein soll, wie genau die Liste nun dargestellt wird?

Wenn ich eine Desktopanwendung schreibe und der Benutzer aus mehreren Optionen wählen soll, dann erstellt der Controller doch auch nicht das GUI Element für die Auswahl und übergibt es dem View ... (GUI Element soll HTML Tags für Liste entsprechen). Sondern es ist ihm egal, solange das View irgendwann sagt welche Option ausgewählt wurde.


Die Antwort liefert dir einmal das Bild von der oben gezeigten Seite sowie ein Zitat aus dem Text:

Es würden hier bestimmt Funktionen wie aktualisiereWennNeueNachricht() oder aktualisiereWennMehrAlsEinBenutzer() beschrieben werden, wenn man wirklich nach deinem Prinzip gehen würde und den View danach zu bauen, welche Daten reinkommen.

Nein. In aktualisiere() würde das View die Daten aus dem Model holen uns sie irgendwie darstellen.
Erneut zum Beispiel Array: Es könnte das Array einfach Ausgeben, dann hat der Benutzer etwas wie "Array ( Eintrag 1, Eintrag 2, Eintrag 3)". Das ist aber hässlich, also erstellt das View eine schöne Liste mit HTML Tags. Und statt "Array ( )" zeigt es eine Meldung an. Mehr nicht ...
Gegenfrage: Hätte der Controller bei deiner Variante nicht ein Methode wie "erstelleGUIElementFürArrayAusgabe()"?

Ich finde, dass das Diagramm sogar eher meine Variante stützt: Das View heißt "KundenHtmlView", d.h. die Ausgabe erfolgt als HTML. Man kann davon ausgehen, dass die Autoren noch mehr Views wie "KundenJSONView" vorsehen, indem die Ausgabe dann in JSON erfolgt. Da sich die Syntax beider "Sprachen" unterscheidet, muss die Ausgabe im View und nicht im zentralen Controller generiert werden.

Aber da auch die Ausgabe (egal welche du nutzt, und ob du nur Links für irgendeine Website setzt) in Zusammenhang mit der Logik steht, ist das völlig irrelevant. Gehen wir mal davon aus du übergibst nicht nur Links, sondern Link-Objekte, die dann die hrefs, targets, alt-attribute und title haben. Diese sind dann in nem Array durcheinander gewürfelt und sollen alphabetisch geordnet werden. Wahrscheinlich würdest du dann auch noch irgendeine Funktion haben die das ganze im View sortiert, aber dass ist ja nicht der Sinn.

Gute Frage. Ich möchte mich nicht festlegen, aber ja, ich würde es vermutlich im View machen, sofern die Sortierung für die restliche Anwendung egal ist.

Erst Recht die Erzeugung des Quellcodes, also das wirkliche eingreifen in die Darstellung beim Nutzer, sollte ausgelagert werden. => Warum? Was ist denn, wenn der Controller sich entscheidet, Daten anders zu senden? Richtig, du darfst den View umbauen. Warum sollte man sich 2 Baustellen machen?

Damit die Darstellung unabhängig von der restlichen Anwendung ist? Damit ich die Darstellung beliebig verändern kann, ohne dabei Controller / Model anfassen zu müssen? Ist das nicht Sinn von MVC?

Der View sollte im besten Fall nie wissen was der Controller zurückgibt da dieses dumme Fenster dann nur zum ausgeben da ist. Eben das er möglichst universell einsetzbar ist und auf jedes Modell schnell angepasst werden kann.

Muss jedes View universell sein? Jedes Model enthält andere Daten, also brauche ich doch auch verschiedene Views um diese anders anzuzeigen, oder?

Zuletzt ein ganz banales beispiel: Gehen wir einfach davon aus, dass wir 2 Controller haben? Controller 1 ist für Benutzereingaben Validierung verantwortlich und Controller 2 für die Verarbeitung. Beide Controller haben aber die Möglichkeit auf den View zuzugreifen der beispielsweise einen Fehler ausgibt. Controller 1 gibt Fehler als String zurück. Controller 2 als Array. Soll dafür jetzt auch noch eine Prüfung gebaut werden?

Oder man nutzt zwei Views. Oder man schiebt den String auch in ein Array und verarbeitet im View immer ein Array mit mehreren Fehlermeldungen (so würde ich es machen).
Als Gegenfrage dient das gleiche HTML / JSON Beispiel wie oben ...

[Synatex]

Wenn ich deine Auffassung richtig verstanden habe, müsste für diese Änderung sowohl Controller als auch View geändert werden.

Dann habe ich es wohl falsch aus meiner Sicht erläutert. Ein Beispiel von mir wäre dies nun:

PHP Code:

<?php

 class Controller
 {

   private $data;

   public function getViewData()
   {
      if(is_array($this->data)) {
         return implode(',',$this->data);
      } else {
         return $data;
      }
   }
 }

?>

view.php

PHP Code:

<html>
<head>
<title></title>
</head>
<body>
<section>
<?=$content;?>
</section>
</body>
</html>

Hier sehe ich einmal die Verarbeitung (also was passiert, wenn Daten dem oder dem entsprechen), und einmal die Ausgabe, nämlich dass, was die Verarbeitung entschieden hat. Ein Beispiel deiner Methode, so wie ich es mir jetzt vorstellen würde:

view.php

PHP Code:

<html>
<head>
<title></title>
</head>
<body>
<section>
<?php if(is_array($content)) { echo $dies; } else { echo $das; } ?>
</section>
</body>
</html>

So. Was ist denn nun wenn wir einen JSON String übergeben? Bei deiner Methode müsste ich dann in den Controller gehen und den Rückgabewert ändern. ZUSÄTZLICH müsste ich im View eine weitere Überprüfung einbauen, da der String ja auch JSON sein könnte.

In dem oberen Beispiel wären wir im Controller. Wir könnten mit einer einfachen weiteren if() Abfrage dem JSON zurückgeben und dem View wäre es scheiß egal obs nun JSON, ein Array oder ein String in der Verarbeitung war, denn das was es kriegt war dann nen String.

Hätte der Controller bei deiner Variante nicht ein Methode wie "erstelleGUIElementFürArrayAusgabe()"?

Ja hätte er. Wir können das ganze ja mit dem .NET Framework vergleichen. Einen einfachen Button auf der GUI zu erstellen:

Button btn = new Button(); (Glaub ich?)

So. Nun haben wir unseren Button. Im Hintergrund wird dann schön gezeichnet und deine angesprochene GUI wird erstellt. Aber womit wird die erstellt? Richtig, mit dem Code. Denn dem View ist es dann egal ob der Button oben oder unten platziert ist, der wird dort platziert. Es wird mithilfe von den Eigenschaften des Objektes dann die Höhe,Breite und die Abstände angegeben - aber ein Button wurde trotzdem gemalt, die Unterschiede wurden dann aber durch das Objekt weitergegeben und der View hat es so angenommen.

Oder man schiebt den String auch in ein Array und verarbeitet im View immer ein Array mit mehreren Fehlermeldungen (so würde ich es machen).

Das heißt du würdest die universelle Funktion des Controllers schon dazu missbrauchen um Daten für den View vorzubereiten der im Grunde für die Anzeige verantwortlich ist nun aber durch dich Logik erhält?

Aber wie bereits am Ende des anderen Topics gesagt, es nützt dem Threadersteller nichts und es wird auch weiterhin die Meinung jedes bleiben, ob und wie er Templatesysteme einsetzen will und wie der die Views handhabt

[Phillor]

Gut. Habe mich für PHP als Templatesystem an sich entschieden.
Habe eine Templateklasse gefunden, allerdings ohne caching. Naja egal, mal schauen, wies funktioniert.

[dowhile]

Ich dachte mir das so:

class Controller {

    private $data;

    public function getViewData() {
        $buffer = '';

        if (count($this->data) == 0) {
            $buffer .= '<p>Keine Eintraege vorhanden.</p>';
        } else {
            $buffer .= '<ul>';
            foreach ($data as $entry) {
                $buffer .= '<li>' . $entry . '</li>';
            }
            $buffer .= '</ul>';
        }

        return $buffer;
    }
}

Da im View kein HTML generiert werden darf, muss die Liste im Controller generiert werden. Das View sieht weiterhin so aus wie in deinem Beitrag.

Nun soll die API realisiert werden. Statt JSON nehme ich jetzt XML, da ich mich mit der Syntax von JSON nicht auskenne:

<entries>
    <entry>Eintrag #1</entry>
    <entry>Eintrag #2</entry>
</entries>

oder, wenn keine Einträge vorhanden sind:

<entries>
</entries>

In deinem Beispiel müsste nun der Controller die Liste mit den <entries> Tags generieren. Zusätzlich muss ein anderes View genutzt werden, denn die zusätzliche HTML Tags in view.php sollen in der Ausgabe nicht auftauchen.

Es muss also sowohl Controller als auch View modifiziert werden, obwohl sich nur die Darstellung der Daten ändert. Nach meiner Auffassung müsste in einem solchen Fall nur ein zweites View erstellt werden; der Controller lädt dann je nach Anfrage das richtige View und muss sich nicht darum kümmern, wie genau die Darstellung nun erfolgt.

Wird später noch eine dritte Ausgabeform benötigt, muss erneut nur ein anderes View hinzugefügt werden; der Controller muss dazu nicht modifiziert werden. Ist nicht genau das der Vorteil, den uns MVC bringt?

In dem oberen Beispiel wären wir im Controller. Wir könnten mit einer einfachen weiteren if() Abfrage dem JSON zurückgeben und dem View wäre es scheiß egal obs nun JSON, ein Array oder ein String in der Verarbeitung war, denn das was es kriegt war dann nen String.

Ich glaube, dass du mich nicht richtig verstanden hast. Ich dachte mein Beispiel so, dass eine Liste einmal als HTML Liste für Nutzer mit Browser ausgeliefert wird und einmal als JSON / XML / was auch immer API für andere Anwendungen.
Es geht also nicht darum, dass das View unterscheiden muss, ob der String JSON / HTML / ... ist. Es soll die Daten einmal als HTML und einmal als JSON/XML zur Verfügung stellen.
Von der anderen Seite: Durch möchte ich mir die Liste im Browser anschauen und mit soll die Liste für andere Anwendungen mit JSON/XML ausgegeben werden.

So. Nun haben wir unseren Button. Im Hintergrund wird dann schön gezeichnet und deine angesprochene GUI wird erstellt. Aber womit wird die erstellt? Richtig, mit dem Code. Denn dem View ist es dann egal ob der Button oben oder unten platziert ist, der wird dort platziert. Es wird mithilfe von den Eigenschaften des Objektes dann die Höhe,Breite und die Abstände angegeben - aber ein Button wurde trotzdem gemalt, die Unterschiede wurden dann aber durch das Objekt weitergegeben und der View hat es so angenommen.

Das verstehe ich nicht so ganz. Der Button ist doch Teil vom View, oder?

Das heißt du würdest die universelle Funktion des Controllers schon dazu missbrauchen um Daten für den View vorzubereiten der im Grunde für die Anzeige verantwortlich ist nun aber durch dich Logik erhält?

Was du damit meinst, ist mir, ehrlich gesagt, auch nicht so ganz klar.