Konzept-Problem bei MVC-View und View-Renderer

dsentker · 13.01.2012, 11:04

Huhu,

ich hoffe ich kann mein Problem erläutern.

Also, ich habe eine View-Klasse, die im Controller genutzt wird und so funktioniert, wie ihr es auch kennt:

PHP-Code:

 
// im Controller
$this->view->assign('foo', $bar);
$this->view->baz = array('qux', 'foo');

// in dem Template
<h1><?= $this->foo; ?></h1>
<ul>
  <?php foreach($baz as $b) : ?><li><?= $b ?></li><?php endforeach; ?>
</ul>

Soweit, so gut. Nun habe ich mir gedacht, dass es ja den Fall geben könnte, das jemand nicht mit der PHP-nativen Template-"Engine" arbeiten möchte, sondern mit Twig, Smarty oder Konsorten (oder eine eigene nutzen möchte). In diesem Fall sollte die Komponente leicht zu wechseln sein.
Mir kam der Gedanke des "Renderers". Der o.g. ist demnach ein PHPRenderer, es könnte also auch einen TwigRenderer geben etc.
Die Grundstrukturen einer View, unabhängig vom Rendering, sind natürlich immer die gleichen: View instanziieren, Template-Datei festlegen, Werte zuweisen und abschließend ausgeben.

Die Klasse "View" bekommt nun also via DI einen Renderer im Konstruktor spendiert, den er benutzt, sobald $view->render() benutzt wird. Die View-Klasse holt sich nun den Renderer, übergibt diesme die View-Datei, die Variablen und andere Optionen, da der Renderer damit ja arbeiten muss.
Meine View-Objekte sollen in der Lage sein, ein übergeordnete View festzulegen (vgl. Symfony2 - Slots). Ich möchte jedoch die Freie Wahl lassen, die Parent-View im Controller oder im Template selbst festzulegen. Ich möchte also sowohl aus dem Template in der Lage sein, $this->setParent(...) zu benutzen, als auch diese Angabe im Controller durchzuführen.

Nun habe ich aber ein Problem:
Bevor ich meinen Renderer ausgelagert habe, konnte ich innerhalb der Template-Datei bequem die Parent-View festlegen:

PHP-Code:

  <?php
// Template
/** @var $this \Path\To\ViewClass */
$this->setParent('index');
?>
<h1>Hallo!</h1>
<!-- etc. ... -->

Das geht jetzt nun nicht mehr, da $this im Template nun auf den Renderer zeigt, und nicht mehr auf die View. Wenn ich nun die setParent()-Methode in den Renderer verlege, kann ich nicht mehr vom Controller aus die Methode benutzen. Es ist ja nicht nur die setParent()-Methode, sondern auch andere Dinge. Etwa ViewHelper, festgesetzte Variablen etc: Alles muss ich von der View-Klasse aus in den Renderer schaufeln. Wenn ich also die setter/getter für diese vielen Kleinigkeiten sowohl im Renderer als auch in der View habe, kommt eine Menge Redundanz auf.

Möglichkeiten:
1. Den Renderer wieder in die View integrieren und auf Unterstützung für andere Template-Engines verzichten
2. Die getter/setter in den Renderer schaufeln und die Brücke nutzen:

PHP-Code:

  $this->view->getRenderer()->setParent($foo);

3. Die getter/setter in der ViewKlasse belassen, aber beim Aufrufen des Renderers die eigene Instanz in den Renderer übergeben:

PHP-Code:

  // ViewKlasse
public function render() {
   $renderer = $this->getRenderer();
   $renderer->setView($this);
   $renderer->setTemplateFile($this->getTemplateFile());
   $renderer->setViewVars($this->getViewVars());
}

// innerhalb des Templates, die via $this auf den Renderer zugreifen kann
$this->getView()->setParent($foo);

Was sagt ihr? Freue mich über jede Form von Input von euch, da ich mich momentan festgefahren fühle.

tr0y · 13.01.2012, 11:10

einheitliche ViewInfo-Objekte generieren mit denen der Renderer arbeitet und die ViewInfo-Objekte miteinender Verknüpfen, statt die Views zu schachteln.

Andernfall knallst du immer wieder gegen die Schallmauer "Facade".

dsentker · 13.01.2012, 11:24

Mh, das könnte ein Ansatz sein.

Wenn ich also eine art "ViewInfo"-Objekt habe, das mit Template-Variablen bestückt werden kann und andere Optionen zum Template beinhaltet (übergeordnetes Template, StrictAnAus etc), habe ich doch ebenfalls eine Facade-Invasion? Stellvertretend für die vielen Methoden nehme ich mal "assign()":

PHP-Code:

  //Controller
$this->view->assign('foo', $bar);

// View-Objekt
public function assign($key, $val) {
   $this->getViewInfo()->assign($key, $val);
}

// ViewInfo-Objekt
public function assign($key, $val) {
   $this->templateVars[$key] = $val;
}

// Renderer, Zugriff möglich aus der View
public function assign($key, $val) {
    $this->getViewInfo()->assign($key, $val);
}

// Template
$this->assign('key', 'value');

tr0y · 13.01.2012, 11:36

Nein, generell nicht, die ViewInfo-Objekte verhalten sich so als würden sie als reale Views ohne irgendwelche Renderer fungieren. Der Renderer der die Templates dann zusammenschnitzeln wird sollte dieses Objekt-konstrukt dann nur traversieren und dort dann beispielsweise irgendwelche Template-Objekte erzeugen und die Daten durchreichen ( des jeweiligen ViewInfo ), du dann also im endeffekt nur "fetch($key)" für den Renderer nutzt und der rest intern im Renderer "assigned" wird.

dsentker · 13.01.2012, 11:47

Ich komme glaube ich nicht ganz mit.
Beschreibst du nicht das, was ich oben bereits genannt habe?
Beim Aufruf des Renderers wird die Instanz der ViewKlasse bzw. der ViewInfo-Klasse übergeben. Der Renderer muss sich nur noch die Informationen aus der ViewKlasse bzw. der ViewInfo-Klasse ziehen, die er braucht.

tr0y · 13.01.2012, 13:14

Zitat:

Zitat von dsentker

Ich komme glaube ich nicht ganz mit.
Beschreibst du nicht das, was ich oben bereits genannt habe?
Beim Aufruf des Renderers wird die Instanz der ViewKlasse bzw. der ViewInfo-Klasse übergeben. Der Renderer muss sich nur noch die Informationen aus der ViewKlasse bzw. der ViewInfo-Klasse ziehen, die er braucht.

Der Renderer bekommt nur die ViewInfo-Klasse, und sollte sie selbst nicht manipulieren.

normal:
Controller -> 1 View [ x Sub-Views ] => Output

was ich vorschlug

Controller -> 1 View -> 1 Renderer-Facade ( -> x ViewInfo ) => Output

Was du meinst:

Controller -> 1 View <-> 1 Renderer-Facade ( <-> x ViewInfo ) => Output

Trainmaster · 13.01.2012, 13:31

Zitat:

Zitat von tr0y

Controller -> 1 View -> 1 Renderer-Facade ( -> x ViewInfo ) => Output

Wieso nicht gleich:

Controller -> Renderer-Facade ( -> x ViewInfo ) => Output

?

tr0y · 13.01.2012, 13:36

Zitat:

Zitat von Trainmaster

Wieso nicht gleich:

Controller -> Renderer-Facade ( -> x ViewInfo ) => Output

?

Wenn man den View als Renderer-Facade realisiert, klar.

Andernfalls bleibt man so flexibel das man 0815 Views weiterhin nutzen kann und die Option behält ein View zu schaffen das Renderer bedient. Das View also nicht mit Renderer-Routinen zumüllt.

dsentker · 13.01.2012, 13:46

Okay, das macht Sinn. Wenn ich also vom Controller aus eine Variable in einem Template belegen möchte, spreche ich die Renderer-Facade an, welches diese Information dann an die richtige ViewInfo weitergibt?

xm22 · 13.01.2012, 13:54

Wieso nicht einfach eine abstrakte View-Klasse, die entsprechend abgeleitet wird? HtmlView, TwigView, etrc.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Problem mit MVC und Ajax Request, responseText kommt als gesamtes Layout zurück	litterauspirna	PHP Einsteiger	39	30.12.2011 20:12
View Helper in View Objekt verfügbar machen?	litterauspirna	PHP Einsteiger	1	27.12.2011 15:22
Problem mit swfobjects	R4v3r	JavaScript, Ajax und mehr	8	21.09.2008 14:17
Search - Result - View Problem		PHP Tipps 2005-2	2	04.09.2005 08:54

13.01.2012, 11:04
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Konzept-Problem bei MVC-View und View-Renderer Huhu, ich hoffe ich kann mein Problem erläutern. Also, ich habe eine View-Klasse, die im Controller genutzt wird und so funktioniert, wie ihr es auch kennt: PHP-Code: `// im Controller $this->view->assign('foo', $bar); $this->view->baz = array('qux', 'foo'); // in dem Template <h1><?= $this->foo; ?></h1> <ul> <?php foreach($baz as $b) : ?><li><?= $b ?></li><?php endforeach; ?> </ul>` Soweit, so gut. Nun habe ich mir gedacht, dass es ja den Fall geben könnte, das jemand nicht mit der PHP-nativen Template-"Engine" arbeiten möchte, sondern mit Twig, Smarty oder Konsorten (oder eine eigene nutzen möchte). In diesem Fall sollte die Komponente leicht zu wechseln sein. Mir kam der Gedanke des "Renderers". Der o.g. ist demnach ein PHPRenderer, es könnte also auch einen TwigRenderer geben etc. Die Grundstrukturen einer View, unabhängig vom Rendering, sind natürlich immer die gleichen: View instanziieren, Template-Datei festlegen, Werte zuweisen und abschließend ausgeben. Die Klasse "View" bekommt nun also via DI einen Renderer im Konstruktor spendiert, den er benutzt, sobald $view->render() benutzt wird. Die View-Klasse holt sich nun den Renderer, übergibt diesme die View-Datei, die Variablen und andere Optionen, da der Renderer damit ja arbeiten muss. Meine View-Objekte sollen in der Lage sein, ein übergeordnete View festzulegen (vgl. Symfony2 - Slots). Ich möchte jedoch die Freie Wahl lassen, die Parent-View im Controller oder im Template selbst festzulegen. Ich möchte also sowohl aus dem Template in der Lage sein, $this->setParent(...) zu benutzen, als auch diese Angabe im Controller durchzuführen. Nun habe ich aber ein Problem: Bevor ich meinen Renderer ausgelagert habe, konnte ich innerhalb der Template-Datei bequem die Parent-View festlegen: PHP-Code: `<?php // Template /** @var $this \Path\To\ViewClass / $this->setParent('index'); ?> <h1>Hallo!</h1> <!-- etc. ... -->` Das geht jetzt nun nicht mehr, da $this im Template nun auf den Renderer zeigt, und nicht mehr auf die View. Wenn ich nun die setParent()-Methode in den Renderer verlege, kann ich nicht mehr vom Controller aus die Methode benutzen. Es ist ja nicht nur die setParent()-Methode, sondern auch andere Dinge. Etwa ViewHelper, festgesetzte Variablen etc: Alles muss ich von der View-Klasse aus in den Renderer schaufeln. Wenn ich also die setter/getter für diese vielen Kleinigkeiten sowohl im Renderer als auch in der View habe, kommt eine Menge Redundanz auf. Möglichkeiten: 1. Den Renderer wieder in die View integrieren und auf Unterstützung für andere Template-Engines verzichten 2. Die getter/setter in den Renderer schaufeln und die Brücke nutzen: PHP-Code: `$this->view->getRenderer()->setParent($foo);` 3. Die getter/setter in der ViewKlasse belassen, aber beim Aufrufen des Renderers die eigene Instanz in den Renderer übergeben: PHP-Code: `// ViewKlasse public function render() { $renderer = $this->getRenderer(); $renderer->setView($this); $renderer->setTemplateFile($this->getTemplateFile()); $renderer->setViewVars($this->getViewVars()); } // innerhalb des Templates, die via $this auf den Renderer zugreifen kann $this->getView()->setParent($foo);` Was sagt ihr? Freue mich über jede Form von Input von euch, da ich mich momentan festgefahren fühle. __________________ Geändert von dsentker (13.01.2012 um 11:08 Uhr).*


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

13.01.2012, 11:10
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	einheitliche ViewInfo-Objekte generieren mit denen der Renderer arbeitet und die ViewInfo-Objekte miteinender Verknüpfen, statt die Views zu schachteln. Andernfall knallst du immer wieder gegen die Schallmauer "Facade". __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

13.01.2012, 11:24
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Mh, das könnte ein Ansatz sein. Wenn ich also eine art "ViewInfo"-Objekt habe, das mit Template-Variablen bestückt werden kann und andere Optionen zum Template beinhaltet (übergeordnetes Template, StrictAnAus etc), habe ich doch ebenfalls eine Facade-Invasion? Stellvertretend für die vielen Methoden nehme ich mal "assign()": PHP-Code: `//Controller $this->view->assign('foo', $bar); // View-Objekt public function assign($key, $val) { $this->getViewInfo()->assign($key, $val); } // ViewInfo-Objekt public function assign($key, $val) { $this->templateVars[$key] = $val; } // Renderer, Zugriff möglich aus der View public function assign($key, $val) { $this->getViewInfo()->assign($key, $val); } // Template $this->assign('key', 'value');` __________________

13.01.2012, 11:36
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Nein, generell nicht, die ViewInfo-Objekte verhalten sich so als würden sie als reale Views ohne irgendwelche Renderer fungieren. Der Renderer der die Templates dann zusammenschnitzeln wird sollte dieses Objekt-konstrukt dann nur traversieren und dort dann beispielsweise irgendwelche Template-Objekte erzeugen und die Daten durchreichen ( des jeweiligen ViewInfo ), du dann also im endeffekt nur "fetch($key)" für den Renderer nutzt und der rest intern im Renderer "assigned" wird. __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

13.01.2012, 11:47
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Ich komme glaube ich nicht ganz mit. Beschreibst du nicht das, was ich oben bereits genannt habe? Beim Aufruf des Renderers wird die Instanz der ViewKlasse bzw. der ViewInfo-Klasse übergeben. Der Renderer muss sich nur noch die Informationen aus der ViewKlasse bzw. der ViewInfo-Klasse ziehen, die er braucht. __________________

13.01.2012, 13:46
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Okay, das macht Sinn. Wenn ich also vom Controller aus eine Variable in einem Template belegen möchte, spreche ich die Renderer-Facade an, welches diese Information dann an die richtige ViewInfo weitergibt? __________________

13.01.2012, 13:54
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Wieso nicht einfach eine abstrakte View-Klasse, die entsprechend abgeleitet wird? HtmlView, TwigView, etrc.