[pmayer]

Hey!

Ich habe folgendes Problem:

Mein Controller hat verschiedene Methoden z.B. validate und insert. Jede Methode hat gemeinsam, dass via $view->assign ("key", "value"); daten an den view übergeben werden und am Ende $view->render (...); aufgerufen wird. Das funktioniert super wenn ich ohne AJAX arbeite. Wenn ich aber AJAX verwende will ich nur, dass die Daten zurückgegeben werden z.B. bei valid Fehlermeldungen und bei insert eine Erfolgsmeldung und nicht, dass mir hier der View die komplette Seite gerendert zurückgibt und ich mir mit JavaScript die Infos selbst rausparsen kann .

In Code würde ein Controller so aussehen:

PHP-Code:

<?php
class Controller {
     public function sthAction () {
         $view = $this->getViewInstance ();

        // Logik

         $view->render ("some/template");
    }
}

Jetzt hab ich mir gedacht ich schreibe mir für jeden Controller eine Hilfsklasse die die gesamte Logik enthält und dann im Controller instanziert wird und von der die View Komponente die Daten bekommt.
Somit könnte ich mir nen XML-RPC oder JSON-RPC Server schreiben, an dem meine AJAX Requests gehen und der dann eben wirklich nur die für den AJAX Request relevanten Daten zurückgibt.

Was haltet ihr davon bzw. wie habt ihr das Problem gelöst und was kann man an der Idee verbessern?

-- Peter

[Basti]

Hi Peter.

Was heißt denn für dich "Logik"? Sieht so aus, als hättest du deine Controller mit Funktionen überfrachtet, die eigentlich in der Model-Schicht sinnvoller aufgehoben wären. Das Validieren und Einfügen von Daten gehört doch in die Datenschicht. Der Controller gibt die Daten nur aus dem Request weiter, schaut, was passiert und reagiert entsprechend (z.B. mit einer erneuten Anzeige mit Fehlermeldung oder einem Redirect bei Erfolg).

Auch ist es nach meiner Erfahrung wenig sinnvoll, das Rendern der View im Controller zu veranlassen.

Konkret zu deinem Problem denke ich, dass du nur entweder zwei Controller bauen musst, oder deine Architektur so umbauen musst, dass dein System auch bei einer "normalen" Anfrage wie ein Ajax-System funktioniert, dass du also den Status der View speicherst und in den Controllern eben auch nur die Veränderungen durchgibst (siehe z.B. PRADO oder auch der aktuelle Thread hier im Forum zu diesem Thema).

Ein anderer Weg, der mir gerade kommt ist, den Views so zu erweitern, dass sie in der Lage sind, die Daten direkt aus dem Request zu beziehen bzw. quasi als halbe Umsetzung der Speicherung der ViewStates könntest du Widgets in die Views setzen und noch vor dem Ansprechen der Controller erstmal alle Request-Daten quasi zurück durch die Widgets jagen, damit du diese eben gar nich nochmal neu füttern musst:

PHP-Code:

class Register
{
    public function init()
    {
        return $this->createView('RegisterForm');
    }

    public function execute($View)
    {
        $Form = $View->get('form');

        if ($Form->sent()) {

            $User = User::create($Form->userdata);

            if ($User->isValid()) {

                $User->save();
                return new Redirect('user.prefereces', new Message('user', 'register_success'));

            }
        }

        if (isset($User) {

            // sowas waere dann halt nicht mehr noetig:
            // $View->assignDataObject('userdata', $User);
            $Form->setMessage(new Message('user', 'register-invalid'));
            $Form->setErrors($User->getErrors);
        }
        return $View;
    }
} 


Je nach FrontController werden hier halt andere Views geladen (View_User_RegisterForm_Ajax, View_User_RegisterForm_Html), die dann eben auch andere Methoden anbieten (die natürlich in abstrakten Klassen gekapselt sind). Einmal werden die Widgets manipuliert (HTML) und im anderen Fall werden eben die Daten gesammelt und als XML-Response an den JavaScript-Client geschickt.

Irgendwie so vielleicht?

Basti

[pmayer]

danke für die antwort!

Ja so in der Art werde ich es auch machen d.h. den View über eine factory methode zu erzeugen, die dann aufgrund der HTTP Header entscheidet ob es ein XMLHttpRequest ist oder nicht und dann halt eine entsprechende unterklasse von View zurückgibt.

mfg peter

[Basti]

Zitat von pmayer

Ja so in der Art werde ich es auch machen d.h. den View über eine factory methode zu erzeugen, die dann aufgrund der HTTP Header entscheidet ob es ein XMLHttpRequest ist oder nicht und dann halt eine entsprechende unterklasse von View zurückgibt.

Macht es nicht Sinn, diese Abfrage viel früher anzusiedeln bzw. je nach Methode einen eigenen FrontController anzubieten?

Basti

[Ben]

Ich würd eher pro "Sektion" einen FrontController haben. Ist beim Zend Framework ja ähnlich gelöst.

Also, dass z.B. für .xy/blog/ BlogController, für .xy/search/ SearchController, ... verwendet wird.

Entschlackt das Ganze etwas und macht es in meinen Augen sehr, sehr übersichtlich und klar abtrennbar.

[Basti]

Zitat von Ben

Ich würd eher pro "Sektion" einen FrontController haben. Ist beim Zend Framework ja ähnlich gelöst.

Also, dass z.B. für .xy/blog/ BlogController, für .xy/search/ SearchController, ... verwendet wird.

Entschlackt das Ganze etwas und macht es in meinen Augen sehr, sehr übersichtlich und klar abtrennbar.

Die Frage ist halt, worin sich "blog" und "search" unterscheiden. Wahrscheinlich wird doch der ganze Rahmen (HTML-Request bzw. -Kontext, gleiches Layout, gleiche Navigation, gleiches Rahmen-Template etc. - von übrigen Setup der Anwendung mal ganz abgesehen) identisch sein, was in meinen Augen keinen eigenen FrontController rechtfertigt.

Basti

[Ben]

Wobei die Frage auftaucht, was ein FrontController ist.
Ist aber auch egal, will da an dieser Stelle gar nicht drüber diskutieren, weil es schlicht "Offtopic" wäre.

[dr.e.]

Zitat von Ben

Wobei die Frage auftaucht, was ein FrontController ist.

<klugscheiß>Da muss ich wiedersprechen. Ein FrontController ist in seinem gleichnamigen Pattern klar definiert. Er übernimmt das Handeln von Requests und baut das Model der Applikation auf. Um einen View zu erzeugen verwendet man üblicherweise einen Controller im PageController-Stil.</klugscheiß>

[pmayer]

Zitat von Basti

Macht es nicht Sinn, diese Abfrage viel früher anzusiedeln bzw. je nach Methode einen eigenen FrontController anzubieten?

Basti

Verstehe ich jetzt nicht ganz. Was soll das bringen? Meine gesamte Logik ist für jeden Request gleich, nur die Ausgabe ist eine andere und deshalb lad' ich halt nen eigenen View je nach Art des Requests.

Also meine getView() Methode sieht derzeit so aus:

PHP-Code:

abstract class Controller {
    public function getView ($template) {
        $isAjax = $this->request->isXmlHttpRequest ();

        if ($isAjax) {
            return new JsonView ("UTF-8", $this->response);
        } else {
            return new HtmlView ("UTF-8", $template, $this->response);
        }
    }
}

public abstract function execute (); 


und wird in der execute Methode aufgerufen:

PHP-Code:

class IndexController extends Controller {
    public function execute () {
        $view = $this->getView ("Index");
    }
} 


Die JSON implementierung des Views sieht so aus:

PHP-Code:

class JsonView extends View {

    public function render () {
        $result = new stdClass ();
        $result->message = $this->encode ($this->message);
        $result->result  = $this->encode ($this->result);

        foreach ($this->errors as $key => $error) {
            $this->errors[$key] = $this->encode ($error);
        }

        $result->errors  = $this->errors;

        /**
         * @see http://www.ietf.org/rfc/rfc4627
         */
        $this->response->setHeader ("Content-Type: application/json;charset={$this->settings["encoding"]}");
        echo json_encode ($result);
    }
} 


und die isXmlHttpRequest Methode des Request objekts sieht so aus:

PHP-Code:

 class HttpRequest extends Request {

    public function __construct (array $filters = array ()) {
        parent::__construct (array_merge ($_REQUEST, $_FILES), $filters);
    }
    ...
    public function isXmlHttpRequest () {
        return isset ($_SERVER["HTTP_X_REQUESTED_WITH"]) &&
               $_SERVER["HTTP_X_REQUESTED_WITH"] == "XMLHttpRequest";
    }
} 


Ist eine solche Lösung denn gut?

MfG Peter

[Basti]

Zitat von pmayer

Verstehe ich jetzt nicht ganz. Was soll das bringen? Meine gesamte Logik ist für jeden Request gleich, nur die Ausgabe ist eine andere und deshalb lad' ich halt nen eigenen View je nach Art des Requests.

Na, dann passt es doch. Ich konnte mir nur nicht vorstellen, dass hier der einzige Unterschied liegt. Bei mir sind die Komponenten und so auch die Views immer verschachtelt und im Falle eines Ajax-Requests müste der ganze andere Mist (Navigation etc.) ja nicht extra nochmal aufgebaut werden, aber das sind dann wohl einfach unterschiedliche Konzepte.

Eine Frage habe ich aber:
Was beinhaltet Controller::response?

Und, was den FrontController angeht, so ist das eben die eine Schnittstelle zwischen Server und Anwendung. Ich denke aber schon, dass es Sinn machen kann, hier je unterschiedlicher Verwendungsmethode (HTML, Ajax, CommandLine) je einen eigenen FrontController anzubieten. Mehr FrontController (also je "Sektion") kann ich nicht nachvollziehen. Wundert mich, dass das ZFW diesen Weg geht. Hast du, Ben, da ein konkretes Beispiel?

Basti

[mepeisen]

Zum Zend-Framework: Die FrontController sind ebend nicht klar definiert, da muss ich Ben uneingeschränkt recht geben (Zumindest nach meinem aktuellen Kenntnisstand). Auch die ganzen Tutorials und Artikel von IBM geben darüber keine Auskunft. Mag sein, dass ich was übersehen habe, aber das sei einmal dahingestellt. Andere Tutorials sollte man nicht als Referenz nehmen, denn die machen es ja, wie sie es selber interpretieren.

Fakt ist, dass das Zend Framework eine klare MVC-Trennung vorschreibt. Insofern sind die [Front]Controller also das, was sie vom Namen her sein sollten. Im Prinzip stellt sich nur die Frage, wie man das kapselt, also kapselt man es
- pro Webseite (also ein Controller für alles)
- pro Funktionalität (ein Controller pro Modul o.ä.)
- pro Ausgabeziel (ein Controller für HTML, eines für JSon/Ajax-Kombi)

Jeder mag es wohl so machen, wie er will. Fakt ist lediglich, dass man mit Ajax in leichte Schwierigkeiten kommt, das Design einzuhalten. Generiert man im gleichen Controller und bei gleicher Methode mal ein HTML anhand der Views, mal ein Ajax (ohne Views), hält man sich nicht mehr an die Definitionen des Zend Frameworks. Daher fällt das Beispiel "ein Controller, ein Action für alles" wohl weg.

Der aktuelle Thread, der oben angesprochen wurde ist übrigens [Design] CMS-System: Seitenstruktur


Ich mache genau sowas aktuell oder zumindest etwas, was vor einem analogen Problem stand. Ich habe einmal das initiale Betreten der Seite, bei der die Webseite aufgebaut werden soll und dann habe ich Ereignisse, die per WebRequest ausgelöst werden und sozusagen nur noch Deltas in Form von Anweisungen zurückschicken sollen, beispielsweise "Ändere Farbe auf XYZ in Komponente ABC".

[pmayer]

Eine Frage habe ich aber:
Was beinhaltet Controller::response?

Ein Response Objekt. Ist im Grunde das gleiche wie das Request Objekt nur eben für die Antwort d.h. ich kann darüber z.B. header manipulieren etc. Das hat eben den Vorteil, dass es das Unit Testing erleichtert. Also anstatt HttpRequest übergeb ich da dann halt ein CliRequest objekt, dass eben auch von Request erbt und hab da dann eine andere implementierung weil unter PHP CLI z.B. kann ich ja keine header senden....

MfG Peter

[Basti]

Danke. Was kann das Objekt noch, außer Header manipulieren?

Basti

[pmayer]

Du kannst damit auch die Ausgabe buffern d.h. die Klasse hat ein Attribut body und mittels appendBody/setBody kannst da was reinschreiben und durch flush alles ausgeben.

MfG Peter