Wo passt Zend_Form in das Model View Controller Paradigma

Zend_Form kann an verschiedenen Stellen betrachtet werden. Es kann nicht als Teil von nur einer Schicht MVC-Muster betrachtet werden.

Zend_Form verwendet zunächst Dekoratoren und Ansichtshelfer, um das Formular zu rendern. An dieser Stelle ist es Teil der Ansichtsebene. Dann führt Zend_Form einen Teil des Modelljobs durch, der den Inhalt filtert und validiert.

Wir wissen, dass die Controller-Ebene Eingaben von der Ansicht rendert und an das Modell weiterleitet. Tatsächlich entscheidet die Controllerschicht, welche Ressource von der Modellschicht geladen werden soll und führt dann die korrekten Aufrufe aus.

Wenn Sie Zend_Form von der Controller-Schicht aufrufen, können Sie davon ausgehen, dass Sie eine Modellressource aufrufen, um Validierungs- und Filteraktionen durchzuführen und zu entscheiden, ob dies eine gültige Eingabe ist oder nicht. Zum Beispiel:

Die Bindung von Formularen an das Modell kann als gute Praxis angesehen werden, da Sie sich beim Ausführen von Filter- und Validierungsaktionen auf der Modellschicht befinden. Also, wie Matthew vorgeschlagen hat:

Aus der Standard-Verzeichnisstruktur können wir sehen, dass sich Formulare nicht im Modellordner oder im Ansichtsordner befinden, weil Zend_Form eine bestimmte Klasse ist, die viele Ressourcen und Ebenen miteinander verbindet. Wenn Sie die Matthews-Post überprüfen, werden Sie feststellen, dass dies genau das ist, was gesagt wird, wenn die Aktions-URL auf das View-Skript gesetzt wird und das Formular an das Modell gebunden ist.

Schließlich können Sie Ihren Kontext analysieren und einen dieser beiden Ansätze auswählen.

Momentan ist meine Wahl, Formulare an Modelle zu binden. Sieht gut aus! Und macht mir viel Sinn.

IMO, Zend_Form wurde entwickelt, um mehrere Hüte zu tragen. Es ist in der Tat eine Brücke zwischen der Ansicht und dem Modell mit einem riesigen Stützstrahl vom Controller.

Anstatt ein Formular einem Modell zuzuweisen, sollten Sie ein oder mehrere Modelle einem Formular zuweisen.

In der Model-Ebene können Sie eine getFormInputs-Methode verwenden, die die für die Dateneingabe erforderlichen Elemente zurückgeben kann. Das Modell interessiert sich nicht dafür, welche Form es verwenden wird, es stellt es nur für diejenigen zur Verfügung, die es wollen.

Erstellen Sie jetzt in Ihrer Formularebene eine setupInput-Methode, die durch ein Array von Modellen geleitet wird, um alle Eingaben zu erfassen. Wenn nur ein Modell vorhanden ist, fügen Sie dem Formular die Eingaben hinzu. Wenn es mehr als ein Modell gab, machen Sie Unterformen.

Ihr Controller wird das Formular initiieren und die Werte an das Modell zurückgeben (siehe Keynes newAction-Methode)

Zend_Form fühlt sich oft wie der merkwürdige Mann aus. Ich denke, jeder Kilometerstand variiert.

In letzter Zeit waren die meisten administrativen Schnittstellen sehr Drag + Drop AJAX-y, und sie erfordern eine Menge HTML und Javascript - tatsächliche Formularelemente sind spärlich. Also habe ich mich entschieden, viele der Features von Zend_Form zu meiden und sie als eine Art View-Helfer mit Filter zu benutzen. Alle meine Validierung erfolgt auf einer separaten Ebene im Modell.

Ich denke, O'Phinneys Idee ist auch sehr sinnvoll. Hier entscheidet er sich dafür, die Form fast als eine Komponente des Domänenobjekts zu betrachten - wo er Geschäftslogik hinzufügen kann. Das hört sich gut an, solange Sie darauf achten, dass die Anzeigelogik für das Formular getrennt bleibt. Wie er bemerkt, geht es um semantischen Sinn. Es gibt nicht unbedingt eine harte und schnelle Regel.