[Chr!s]

Morgen,
derzeit bin ich am Umschreiben meines eigenen kleinen Frameworks, da ich bei dem alten öfter mal auf kleine designtechnische Probleme gestoßen bin. Eines der größten Probleme war für mich beim alten Framework der View.

Bisher hatte ich das immer so gelöst:

PHP-Code:

<?php
$oModel = Model::createMySQLWrapper();
// ...

$oModel -> query("SELECT   memberID, memberNickname
                  FROM     members
                  ORDER BY memberID DESC");

while($oModel -> fetchResult()) {
        $oView -> load('memberList.userRow', VIEW_CACHE_TEMPLATE);
        $oView -> assign('memberID', $oModel -> oResult -> memberID);
        $oView -> assign('memberNickname', $oModel -> oResult -> memberNickname);
        // ...
}
?>

Bei vielen Daten die aus dem Model kommen wird irgendwann der oView -> assign() aufwand ziemlich groß, die Liste immer länger, und das finde ich ziemlich lästig. Nun würde ich gerne andere Lösungsansätze hierfür erfahren. Wenn sich die Ergebnisse automatisch ersetzen lassen sollten, müsste der View ja das Model kennen.

PHP-Code:

<?php
// ...
while($oModel -> fetchResult()) {
        $oView -> render('memberList.userRow', $oModel -> oResult,
                          VIEW_CACHE_TEMPLATE);
}
?>

Entweder so, oder ich konstruiere das Ganze so, dass das Model-Objekt direkt im View bekannt und verwendbar ist.
Nur ist das sinnvoll? Ich würde doch hier z.B. an meine Grenzen kommen, wenn ich eine Überprüfung mache, ob ein User online oder offline ist. Bisher habe ich das immer so gelöst:

PHP-Code:

<?php
// ...
while($oModel -> fetchResult()) {
        // ...
        $oView -> assign('userOnlineOfflineStatus',
                          ($this -> oModel -> oResult -> isOnline == 1) ?
                              $oView -> getRawTemplate('userIsOnline')
                            : $oView -> getRawTemplate('userIsOffline');
}
?>

userIsOnline / userIsOffline waren seperate TemplateDateien mit einem Icon, Text, wie auch immer.

Ich will nicht sämtliche derzeit erhältliche MVC-Frameworks ausprobieren und/oder durchforsten, sondern gerne von euch favorisierte Lösungen anhören. Vielleicht ist da ja auch eine gute Idee für mich dabei.

[Basti]

Hi Chris.

Sieht mr eher so aus, als hättest du ein Problem mit deiner Model-Umsetzung (oder müsstest eines haben). *g

PHP-Code:

$oModel = Model::createMySQLWrapper();
$oModel -> query("SELECT * FROM members");
while($oModel -> fetchResult())
        echo $oModel -> oResult -> memberID; 


Lass dir hier lieber Ergebnslisten zurückgeben (bei ::query()) und Datensätze (fetch()), anstatt das alles zu verstecken. Auch wenn du vielleicht mit der Einschränkung leben kannst, immer nur eine Query komplett abzuarbeiten, bevor du die nächte ansetzt ist es, zumindest würed es mir so gehen, irgendwie komisch, so mit "Luft" zu arbeiten - so ins blaue herein.

Zu deinem Problem:
Die beiden Möglichkeiten (push vs. pull) haben beide Vor- und Nachteile.

Push:
Hier schreibt der Controller (etc.) die Daten in die View. Die großen Vorteile sehe ich hier einmal darin, dass die Kontrolle darüber, welche Daten ausgespuckt werden eben ganz im Controller liegen. Bestehen deine Views also z.B. nur aus Templates, dann kann der Template-Designer nichts falsch machen. Er kann sich auch auflisten lassen,welche Daten in welchen Variablen zur Verfügung stehen und muss sich nicht in das Model-API einarbeiten.

Weiterer Vorteil:
Der Zugriff aus den Views aus den Daten ist sehr einfach. Dort spielt es dann keine Rolle, ob die Daten aus der Datenbank oder aus der Session oder aus dem Request kommen ... oder sonstwoher.

Die Views werden dadurch einiges schlanker. Ohne das kommst du eigentlich nicht umhin, je View nicht nur ein Template, sondern auch eine eigene Klasse schreiben zu müssen. Klassisches Beispiel wären z.B. ein Formular Benutzerprofil. Hier kannst du der View einfach ein Objekt User und ein Objekt Errors (falls die Info nicht in User enthalten ist) übergeben und die View spuckt diese einfach aus - ganz gleich, ob die einzelnen Attribute nun aus der Datenbank, aus der Session oder aus dem Request kommen.

Nachteile:
Für jede Info, die neu in der View ausgegeben werden soll, muss der Controller erweitert werden. Es reicht also nicht, dass der Designer z.B. mal eben noch die Gesamtzahl der Forenbeiträge selbst ausliest und reinschreibt, sondern ein Programmierer muss diesen Wert erst bereitstellen.

Damit werden womöglich auch Daten bereitgestellt, die garnicht benötigt werden.

Weiterer Nachteil ist, dass die Controller hier mit ziemlich belangloser Arbeit überfrachtet werden. Ihr Job ist es ja eigentlich nur, Benutzereingaben auszuwerten, ggf. Änderungen am Model zu veranlassen und zu entscheiden, welche View ausgespuckt werden soll.

Benutzt man pro "Action" eine eigene Klasse, dann hat man lauter "Display"-Klassen, die nichts weiter tun, als Daten auszulesen und in die View zu kopieren.

Pull:
Hier zieht sich die View die Daten selbstaus dem Model. Ist ja eigentlich so definiert in MVC (wenn man da von "definiert" sprechen kann). Die Vor- und Nachteile sind hier entsprechend andersrum: Vor allem eben ist es aufwändiger, Views umzusetzen, dafür sind aber alle Daten verfügbar.

Ich beutze die Push-Methode, hab aber beide Möglichkiten offen, da für jede View auch optional eine Klasse definiert werden kann, die auf das Model Zugriff hat. Benutze das aber praktisch nicht.

Was ich dabei noch nicht umgesetzt hab, sind Ergebnislisten (also Zeiger auf MySQL-Query-Results), die direkt an die View übergeben werden, ohne vorher in PHP-Arrays oder Objekte kopiert worden zu sein. Die Listen könnten eine einheitliche Schnittstelle zu anderen Objektlisten haben und entsprechend dekorierbar sein. Das würde den Speicher natürlich schonen.

Die Werte, die für die View bestimmt sind, mache ich zu öffentlichen Eigenscheiften der Controller. Anstatt $View->assign('User', $User) schreibe ich dann halt $this->User = $User. Ist sehr schön für schreibfaule, aber ganz glücklich bin ich damit nicht.

Zitat von Chr!s

Nun würde ich gerne andere Lösungsansätze hierfür erfahren. Wenn sich die Ergebnisse automatisch ersetzen lassen sollten, müsste der View ja das Model kennen.

Was meinst du mit "automatisch ersetzen lassen"?

Ich würde doch hier z.B. an meine Grenzen kommen, wenn ich eine Überprüfung mache, ob ein User online oder offline ist. Bisher habe ich das immer so gelöst:

PHP-Code:

<?php
// ...
while($oModel -> fetchResult()) {
        // ...
        $oView -> assign('userOnlineOfflineStatus',
                          ($this -> oModel -> oResult -> isOnline == 1) ?
                              $oView -> getRawTemplate('userIsOnline')
                            : $oView -> getRawTemplate('userIsOffline');
}
?>

userIsOnline / userIsOffline waren seperate TemplateDateien mit einem Icon, Text, wie auch immer.

Dafür kannst du einfach Komponenten definieren, die du in der View in Abhängigkeit der Daten, die diese zur Verfügung hat einbindet (ComponentView).

Basti

[robo47]

wie wärs wenn dein assign arrays aktzeptiert ? index ist dann variablennamen und inhalt = inhalt, so wie beispielsweise smarty auch arrays beim assign akzeptiert.

[Basti]

...oder eben Objekte, die Ergebnislisten enthalten, deren Datensätze erst beim Iterieren darüber in den PHP-Speicher kopiert werden und dabei vielleicht per Dekoratoren in entsprechende Objekte umgewandelt werden können, mit denen z.B. die Widgets dann wieder was anfangen können (oder auch i18n-Funktionen etc.).

PHP-Code:

Controller:

$this->Userlist = $this->UserPeer->getListByName(0, 20);


UserPeer (oder wie auch immer zu benennen:(

return new UserList($this->Dao->getListByName(0, 20));

UserList:

extends TransferObject implements Iterator

public function next()
{
    return new User($this->Result->fetch());
}

View:

<loop item="Userlist" assign="User">
    <component id="UserRecord" value="User" />
</loop>

oder:

<table_widget item="Userlist" />

oder klassisch:

<table>
<?php
foreach ($this->Userlist as $User) {
    echo "\t<tr>\n";
    echo "\t\t<td>" . $User->name . "</td>\n";
    ...
    echo "\t</tr>\n";
} ?>
</table>

Basti

[Ben]

Ich verstehe ehrlich gesagt nicht so ganz, was Ihr hier redet?!

Ich hole mir die Daten, habe diese in einem Array, übergebe das an die Template-Engine, die parst die Daten in das Template, das Template wird ausgegeben. Fertig.

Von Bastis Beitrag hab ich etwa Bahnhof verstanden, hab aber auch recht schnell abgeschaltet, weil ich hier keine Bombe brauche, um ein bisschen Unkraut zu entfernen!
Oder habe ich den tieferen Sinn nicht verstanden? Dann bitte um kurze Aufklärung seitens Chr!s.

Danke.

[Basti]

Man braucht sogar weder eine Template-Engine (außer PHP selbst natürlich), noch ein einziges Objekt, um sowas umzusetzen, ist doch klar. Aber es geht ja darum, hier ein wenig zu investieren, um sich das Leben dort ein wenig einfacher zu machen.

Natürlich sind das Kanonen auf Spatzen, wenn du ein Gästebuch, einen Counter, ein Kontaktformular umsetzen möchtest, aber dafür schreibt man sich ja auch kein Framework, oder?!

Basti

[Ben]

Jou, ich verstehe nur nicht so ganz, wozu man da "investiert". Ich sehe keinen Mehrgewinn.

[Basti]

...mal ein Framework rausgepickt, von dem du auch schon berichtet hast:

[...] designed to eliminate the tedious details of coding and let you focus on the big picture.

Und weiter:

[...] making your code more reusable and easier to maintain.

http://framework.zend.com/wiki/pages...n?pageId=10530

Basti

[Ben]

Durchaus.

PHP-Code:

<?php
// use a model to get the data for book authors and titles.
$data = array(
    array(
        'author' => 'Hernando de Soto',
        'title' => 'The Mystery of Capitalism'
    ),
    array(
        'author' => 'Henry Hazlitt',
        'title' => 'Economics in One Lesson'
    ),
    array(
        'author' => 'Milton Friedman',
        'title' => 'Free to Choose'
    )
);

// now assign the book data to a Zend_View instance
Zend::loadClass('Zend_View');
$view = new Zend_View();
$view->books = $data;

// and render a view script called "booklist.php"
echo $view->render('booklist.php');
?>

Quelle: http://framework.zend.com/manual/en/zend.view.html

Daten holen, an Template-Engine übergeben, parsen, geparstes Template ausgeben.

[Basti]

...und von da ist`s ja nur noch ein kleiner Schritt, sich aus der Model-Schicht gleich das Objekt/Objektlisten zurückgeben zu lassen und die Ausgabe über eine Template-Engine mit Widgets zu erledigen.

Aber das ist ja auch alles garnicht der Punkt dieser Diskussion. Ich wollte einfach darstellen, dass es grundlegend zwei unterschiedliche Ansätze gibt, wie die View-Schicht an die Daten kommt (bzw. Chris hat das ja so angesprochenund ich hab Vor- und Nachteile beschrieben). Ob das dann mit Arrays oder Objekten, mit Templates, ComponentView, Widgets oder einfachen "PHP-Templates", ob via Queries im Controller oder ORM, DAOs oder was auch immer umgesetzt wird ist dann eine ganz andere, darauf aufbauende Frage.

Hier gehts ja erstmal um die grundlegende Architektur-Entscheidung, ob die View direkten Zugriff auf die Modell-Schicht hat oder eben nur sieht, was man ihr füttert. (Darunter natürlich noch die grundlegendere Entscheidung, ob sich die View per "Observation" des Modells selbst aktualisiert, oder ob sie vom Controller über Änderungen informiert wird, aber das ist im Kontext von PHP-Anwendungen ja eh nicht wirklich Thema.)

In MVC ist es eben klassisch so, dass die View sich die Daten aus dem Model zieht, auch wenn ich das so in PHP noch nicht umgesetzt gesehen hab (hab aber auch noch nicht wirklich danach gesucht).

The view generally have free access to the model, but should not change the state of the model. Views are read only representations of the state of the model. The view reads data from the model using query methods provided by the model.

http://www.phpwact.org/pattern/model...ontroller#view

Basti

PS:
http://www.phpwact.org/pattern/templ...ata_population
Das "pull-Beispiel" finde ich nicht gelungen, da es meiner Ansicht nach nicht wirklich was mit pull zu tun hat. Denn ob man das Template mit Arrays oder mit Zeigern auf Abfrageergebnisse der Datenbank füttert macht vom Prinzip her keinen Unterschied. Letzteres ist halt einfach nur der sauberere Weg, wie oben geschrieben, und auch die logische Weiterführung, wenn man anstatt Arrays eben Objekte verwendet.

Siehe auch z.B. hier:
http://www.phppatterns.com/docs/desi...ct_record_sets

[Ben]

Zitat von Basti

...und von da ist`s ja nur noch ein kleiner Schritt, sich aus der Model-Schicht gleich das Objekt/Objektlisten zurückgeben zu lassen und die Ausgabe über eine Template-Engine mit Widgets zu erledigen.

Womit wir dann wieder beim Bahnhof sind.

Nunja, wenn ich ein bisschen mehr Zeit habe, werde ich mich eventuell mal etwas intensiver mit deinen Beiträgen befassen. Die sind mir zu diesem Zeitpunkt ehrlich gesagt etwas zu .. krass.

Grüße, Ben.

[Chr!s]

Vielen Dank für deine ausführlichen Erkälrungen Basti. Ich werd mir auch nochmal die Links durchsehn, die du gepostet hast, hört sich aber eigentlich sehr gut an.

Was Widgets sind hab ich allerdings noch nicht ganz gerallt

[Chr!s]

Ich hab mich jetzt ersteinmal für eine normale assign() Methode entschieden, und zwar für eine Push Methode. Welche ich nun nehmen soll, weiß ich allerdings noch nicht:

Zuerst hatte ich mir etwas in der Richtung vorgestellt:

PHP-Code:

<?php
// Daten z.B. aus der Datenbank
$aResultset = array('userName' => 'Chris',
                    'origin'   => 'Nürnberg',
                    'birthday' => '29.12.');

$oTemplate = &new templateEngine();
$oTemplate -> load('complexTemplate', TEMPLATE_CACHE_FILE);
$oTemplate -> assign($aResultset);
?>

Dasselbe würde auch mit Objekten gehn (z.B. Objekte, die aus mysql_fetch_object() kommen).

Die Möglichkeit für ein simples assign habe ich allerdnigs auch offen gelassen:

PHP-Code:

<?php
$oTemplate = &new templateEngine();
$oTemplate -> load('complexTemplate', TEMPLATE_CACHE_FILE);
$oTemplate -> assign('userName', 'Chris');
$oTemplate -> assign('origin',   'Nürnberg');
$oTemplate -> assign('birthday', '29.12.');
?>

Nun hab ich mir aber mal überlegt was mich an meiner alten Template-engine am meisten gestört hatte. Das waren u.a. Schleifen, die ich aus der Datenbank ausgelesen hatte. Da hatte ich immer bisher folgendes Konstrukt:

PHP-Code:

<?php
$oModel -> query("...");

$sUserList = '';
while($oModel -> fetchResult()) {
       $oTemplate -> load('userinfo.list', TEMPLATE_CACHE_FILE);
       $oTemplate -> assign('userName', $oModel -> oResult -> userName);
       $oTemplate -> assign('origin', $oModel -> oResult -> origin);
       $oTempalte -> assign('birthday', $oModel -> oResult -> birthday);
       $sUserList .= $oTemplate -> getContent();
}

$oTemplate -> load('userinfo');
$oTemplate -> assign('userList', $sUserList);
$oTemplate -> display();
?>

Finde ich allerdings etwas unpraktisch und aufwändig.
Da hatte ich mir überlegt, dsas bei einem assign() die Werte nicht direkt im Template ersetzt werden, sondern erstmal klassen-intern (private also) in einem Array gespeichert werden - und erst beim rendern ersetzt werden. Dann wären solche Konstrukte möglich:

PHP-Code:

<?php
    $oTempalte -> load('userlist');
    while($oModel -> fetchResult()) {
            $oTemplate -> assign('userList',
                $oTemplate -> loadAndAssign('userlist.list',
                                             array('userName' => $oModel -> oResult -> userName,
                                                   'origin'   => $oModel -> oResult -> origin,
                                                   'birthday' => $oModel -> oResult -> birthday)
                                                   ),
                                             TEMPLATE_CACHE_FILE
                                            );
    }
?>

Was haltet ihr am besten?
Oder noch eine spezielle Funktion ins Template integrieren (was mir aber sicher etwas performance klauen würde, da ich das ja dann erst finden, ausschneiden & parsen müsste)?

PHP-Code:

<?php
// Template
{[loop var="$userList"]}
    <strong>Username:</strong> {{userName}}<br />
    <strong>Herkunft:</strong> {{origin}}<br />
    <strong>Geburtstag:</strrong> {{birthday}}<br />
{[endloop]}
?>

[Basti]

...ganz verstanden hab ich dein Konstrukt da nicht (vorletztes Code-Beispiel), aber ich würde die Iteration in jedem Fall imTemplate machen. Kannst dort ja auch in der Schleife eine Komponente (quasi ein inkludiertes Template-Stück) einbinden, der du den Datensatz als Array oder so mitgibst. (Das wär dann auch schon nicht mehr weit zu den Widgets)

Und, was de Performance angeht, so hab ich noch nie verstanden, wie man auf die Idee kommen kann, in PHP einen Interpreter für Templates zu schreiben, anstatt andersrum die Templates mittes PHP oder XSLT einfach ihrerseits in PHP-Code umzuschreiben. Ich konnte zumindest noch keinen Vorteil der erstgenannten Methode entdecken.

Basti

[Ben]

Zitat von Chr!s

Da hatte ich mir überlegt, dsas bei einem assign() die Werte nicht direkt im Template ersetzt werden, sondern erstmal klassen-intern (private also) in einem Array gespeichert werden - und erst beim rendern ersetzt werden.

Äh, also da muss ich mal fragen, was deine assign()-Methode denn eigentlich macht?

assign() / zuweisen() macht doch genau das, was der Name sagt. Da wird nichts ins Template geschrieben, sondern das passiert erst, wenn du render() display() whatever aufrufst.

Ich lade mir einfach die Daten, z.B. via SELECT daten FROM tabelle, schreibe diese in ein Array, welches ich dann mittels assign() an die Template-Engine übergebe. Ich kann das dann beliebig oft wiederholen und am Ende rufe ich render() auf und der ganze Krimskrams wird in das Template geparsed und das Ergebnis ausgegeben.

[Basti]

...ist ja auch der übliche Weg, würde ich meinen.

Basti

[Chr!s]

Bisher hatte ich das so handgehabt, dass per assign() das Template direkt verändert wird, d.h. in der Methode assign() wird mit str_ bzw preg_replace() das jeweilige Ersetzt.

Zitat von Ben

assign() / zuweisen() macht doch genau das, was der Name sagt. Da wird nichts ins Template geschrieben, sondern das passiert erst, wenn du render() display() whatever aufrufst.

Zitat von Basti

...ist ja auch der übliche Weg, würde ich meinen.

Darauf steuer ich ja auch zu, war ja uach ein Grund, meine Template Klasse zu erneuern.