Le Zend Framework est principalement destiné à une utilisation MVC. L'un des composants très utiles est Zend_form .
J'ai un peu de difficulté à trouver la place de Zend_Form. Cela fait-il partie de la vue, du modèle ou du contrôleur et quelles responsabilités dois-je la donner.
La chose est, zend_form fait deux choses: décorer et rendre la forme et le valider. La première est une tâche de vision réelle, la deuxième tâche de modèle réelle.
L'utilisation la plus courante semble que les formulaires n'interagissent avec le contrôleur qu'avec uniquement les deux tâches (rendu et validation) à la vue / contrôleur.
3 Réponses :
Zend_form se sent souvent comme l'homme étrange. Je pense que le kilométrage de tout le monde varie.
Dernièrement, la plupart de mes interfaces administratives ont été très drags + Drop Ajax-y, et ils nécessitent une bonne affaire de HTML et JavaScript - des éléments de formulaire réels sont clairsemés. J'ai donc choisi d'éviter beaucoup de fonctionnalités de Zend_Form et d'utiliser comme aide à la visualisation de fantaisie avec filtrage. Toute ma validation est effectuée sur une couche séparée dans le modèle.
Je pense que l'idée d'O'Phinney a également beaucoup de sens. Ici, il choisit de penser à la forme presque comme une composante de l'objet de domaine - où il peut ajouter une logique commerciale. Cela semble bien, tant que vous ferez attention à garder toute la logique de vue pour le formulaire séparé. Comme il note, il s'agit de faire un sens sémantique. Il n'y a pas nécessairement une règle dure et rapide.
zend_form peut être visualisé à différents moments. Il ne peut pas être considéré dans le tout comme partie d'une seule couche de motif MVC.
Tout d'abord Zend_Form Utilisez des décorateurs et affichez des aides à rendre le formulaire, à ce stade, il fait partie de la couche de vue. Ensuite, Zend_Form fait partie du modèle Filtrage du travail et validant le contenu. P>
Nous savons que la couche de contrôleur rendit l'entrée de la vue et transmettez-la au modèle. En réalité, la couche de contrôleur décide quelle ressource à charger à partir de couche de modèle puis exécuter les appels corrects. P>
Lorsque vous appelez Zend_Form à partir de la couche de contrôleur, vous pouvez considérer que vous appelez une ressource modèle pour effectuer des valitaux et un filtrage. actions et décider s'il s'agit ou non d'une entrée valide. Par exemple: p>
class Model_DbTable_Users extends Zend_Db_Table
{
protected $_name = 'users';
protected $_form;
public function getForm()
{
if(!$this->_form)
$this->_form = new Form_User();
return $this->_form;
}
public function add($data)
{
$form = $this->getForm();
if(!$form->isValid($data)) return false;
if($form->getValue('id'))
{
$id = (int) $form->getValue('id');
$this->update($form->getValues(), 'id =' . $id);
}
else
{
$id = $this->insert($form->getValues());
}
return $id;
}
}
imo, zend_form est conçu pour porter plusieurs chapeaux. En fait, un pont entre la vue et le modèle avec un faisceau de support géant du contrôleur.
au lieu d'attribuer un formulaire à un modèle, envisagez d'attribuer un modèle à un formulaire.
Dans la couche de modèle, vous pouvez avoir une méthode GETFormInPut pour pouvoir renvoyer les éléments nécessaires aux données d'entrée. Le modèle ne se soucie pas de quelle forme va l'utiliser, il le rend à la disposition de ceux qui leur souhaitent.
Maintenant, dans votre couche de formulaire, effectuez une méthode SetupInputs qui bougera à travers une gamme de modèles pour saisir toutes les entrées. S'il n'y avait qu'un seul modèle, ajoutez les entrées au formulaire. S'il y avait plus d'un modèle, faites des sous-formes.
Votre contrôleur initiera le formulaire et transmettra les valeurs au modèle (voir la méthode de Newaction de Keyne)