Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
bonsoir,
je récupère mes données depuis un formulaire sous le format d'un tableaux et j'utilise les methode Insert et update pour insérer des enregistrements dans ma base de données ce que je trouve très pratique, mais j'ai des exceptions Zend_Db_statment_Exception lorsque me fomulaire renvoi une chaine vide '' pour les champs numériques et dates.
comment parier a ce problème ou doit je parcourir mon tableau pour mettre a NULL mes valeurs vide.
Hors ligne
Je crois que de toute manière il est primordial de contrôler toutes les valeurs saisies et de t'assurer qu'elles l'ont été correctement. Une valeur numérique ne peut pas être vide mais uniquement égale à 0 ou NULL.
Donc oui, il va falloir soit que tu surcharges les fonctions insert() et update() si tu utilises une classe d'accès pour ta table. Soit que tu parcours ton tableau afin de transformer ces valeurs.
Hors ligne
Bonjour,
Le composant Zend_Filter_Input permet de spécifier des filtres et des validateurs à appliquer sur un tableau de données.
Il suffit donc d'indiquer dans le tableau de filtres, les filtres à appliquer sur les bonnes valeurs du tableau.
$filters = array( '*' => 'StringTrim', 'number' => 'Digits' ); $validators= array( );
$data = $_GET; $input = new Zend_Filter_Input($filters, $validators, $data);
ou
$input = new Zend_Filter_Input($filters, $validators); $data = $_GET; $input->setData($data);
Après, pour moi l'idéal et de systématiquement intégrer dans les modèles une méthode de validation des données (avec validateurs et filtres) qui sera utilisée avant chaque save().
A+ benjamin.
Dernière modification par Delprog (17-03-2009 09:17:06)
Hors ligne
il est du ressort du contrôleur de fournir au modèle des valeurs acceptable
c'est donc à lui de remplacer les chaines vide que fournis la vue en null s'il y a lieu
par défaut php garde les chaine vide comme des chaines il ne peut pas être omniscient pour faire des traductions dont il ignore le sens
sur un champs particulier la chaine vide peut être acceptable et significative alors que sur un autre la chaine vide venue de la vue doit être transformée en NULL
A+JYT
Hors ligne
je vous remercie tous pour vos réponse bon j'ai utilisé un foreach pour mettre a null mes chaines vide mais Zend_Filter_Input m'intéresse que je vais certainement utilisé.
Hors ligne
@sekaijin :
D'un point de vu "respect MVC" je suis tout à fait d'accord.
Pour des raisons plus pratiques, j'intègre systématiquement dans mes modèles une méthode de validation des données avant save().
Ca me permet de déplacer mes modèles et de ne jamais avoir à redéfinir ces choses là.
Mon controlleur lui, fait appel à une méthode d'une interface/façade et reçoit une réponse success ou non.
La façade déclenche le processus d'insertion du modèle, comme on l'aurait fait dans le controlleur. Le modèle renvoie une erreur si les données ne sont pas validées pour le save() et la façade ne fait que formater et transmettre le résultat de l'opération au controlleur.
Avant je faisais toutes ces validations dans le controlleur, mais j'ai décidé de procéder ainsi uniquement pour les modèles et pour me faire gagner de l'énergie.
Mis à part le respect du rôle de chacun du point de vue MVC, cette méthode te semble aberrante ?
A+ benjamin.
Hors ligne
dans mon cas j'ai un formulaire très évolué (ExtJS) qui fait pratiquement tous les contrôles de validation au niveau vue mais une vérification niveau serveur est obligatoire moi aussi j'ai la fâcheuse habitude de faire mes contrôles au niveau de mon model en créant des méthodes toutes prête que j'appelle depuis mon contrôleur.
Hors ligne
Delprog a écrit:
@sekaijin :
D'un point de vu "respect MVC" je suis tout à fait d'accord.
Pour des raisons plus pratiques, j'intègre systématiquement dans mes modèles une méthode de validation des données avant save().
Ca me permet de déplacer mes modèles et de ne jamais avoir à redéfinir ces choses là.
Mon controlleur lui, fait appel à une méthode d'une interface/façade et reçoit une réponse success ou non.
La façade déclenche le processus d'insertion du modèle, comme on l'aurait fait dans le controlleur. Le modèle renvoie une erreur si les données ne sont pas validées pour le save() et la façade ne fait que formater et transmettre le résultat de l'opération au controlleur.
Avant je faisais toutes ces validations dans le controlleur, mais j'ai décidé de procéder ainsi uniquement pour les modèles et pour me faire gagner de l'énergie.
Mis à part le respect du rôle de chacun du point de vue MVC, cette méthode te semble aberrante ?
A+ benjamin.
elle pose un problème de portabilité de ton modèle
en déportant une partie du travail du contrôleur sur le modèle du créé une dépendance lorsque tu porteras ton modèle dans une autre application donc vers un autre contrôleur tu devra obligatoirement soit abandonner ce code déporté dans le modèle soit adapter ton contrôleur pour qu'il se comporte comme celui d'origine.
exemple
ton modèle défini les dates en interne dans un type qui lui permet de travailler (peu importe lequel)
dans ma première application qui travaille en français les dates sont échangées en français au format DD/MM/YYYY avec ton approche le modèle accepte une telle date en entrée et se charge de la filtrer la vérifier et la transformer dans sont format interne.
mais voilà que ton application va devoir aussi gérer les dates anglaises donc MM/DD/YYYY il et faut modifier ton modèle parce que ta vue à changée (dépendance des couches) mais pire tu ne sais pas distinguer
le 2 mars 2009 en français du 3 février 2009 en anglais 02/03/2009 la modification du modèle implique donc que le contrôleur lui fournisse en plus la langue de travail donc modification de l'API donc factoring de plusieurs partie de ton application. tu peux envisager de transformer la date avant de la donner au modèle mais alors il te faut la filtrer la valider (au sens syntaxique) la traduire pour la donner au modèle qui va la filtrer la valider (au sens syntaxique) puis la valider sémantiquement.
pire ton modèle part dans une toute autre application ou tes dates à l'interface sont en japonais et en américain littéral soit donc D[kanji Jour)M(Kanji lune)YYYY et W YYYY, m D (Monday 2009 August 5)
là ton modèle n'est plus exploitable il faut lui redéfinir une API nouvelle
une autre approche
dans ton modèle tu use d'un format interne pour tes dates (privé) ton modèle défini une API qui accepte les dates comme étant des chaine au format YYYY/MM/DD
il ne se charge que le la validation sémantique
le contrôleur doit alors se charger de filtrer et de la validation syntaxique mais aussi si besoin de transformer la date pour que le modèle l'accepte.
pour cela tu peux par exemple te faire un plugin de contrôleur tu lui donne une chaine en entrée venant du formulaire et il te la filtre vérifie que c'est une date et te la retourne transformé pour le modèle
comme précédaient tu as travaillé en français et tu dois passer en anglais tu ajoute un méthode à ta classe de contrôle tu branche en fonction de la langue sur la bonne méthode de ta classe de contrôle tu ne touche donc pas à ton modèle
même scénario que précédemment tu place ton modèle dans une autre application qui cause nippon et américain dans cette nouvelle application tu place un pluggin contrôleur adéquat et ça marche
mieux tu peux utiliser le même pluggin et l'améliorer d'appli en appli tu à alors un pluggin gérant les problématique de dates de formulaire indépendant de tes modèles que tu vas pouvoir utiliser sur d'autres modèles
tu es donc gagnant sur toute la ligne
A+JYT
Hors ligne
Salut,
Je n'ai pas parlé de filtrer les données dans le modèle. Je parle simplement d'une méthode de validation qui est utilisée avant n'importe quel save().
C'est donc mon modèle qui porte les validateurs qui correspondent à ce qu'il attend pour un insert ou un update.
Les filtres sont fait dans la façade de mon côté pour rester dans l'idée que si les modèles changent, seule la façade change et donc les filtres qui vont avec.
Les controlleurs eux ne font que déclencher une demande d'insert ou d'update (sous forme normalisée) auprès de la façade, qui se charge de filtrer les données, et de lancer la procédure d'insertion du modèle qui valide les données et retourne un succès ou une erreur que la façade traduit/normalise pour la retourner au controlleur.
Mais ce que tu dis reste quand même valable dans mon cas, dans le sens où je me rend compte que je pourrais aussi bien tout faire dans la façade.
Après, je me demande aussi si le fait d'effectuer toutes ces opérations dans la façade est un bon choix, étant donné que ce n'est pas logiquement son rôle, qui se limite normalement à la traduction de méthodes entre les controlleurs et les modèles.
Je vais réfléchir à tout ça.
A+ benjamin.
Hors ligne
pour rester dans la théorie
la façade ne doit jamais porter de traitement
je maintient que valider syntaxiquement les données dans des plugin de contrôleur est bien plus portable que de le faire dans le modèle car ces plugin ne dépendent pas des modèles il ne dépendent que des type de données véhiculés
il sont donc transportable et peuvent évoluer pour capitaliser le travail.
et tout comme lorsque tu le déporte vers le modèle tu simplifie l'écriture du contrôleur
pour ma part je voit bien un contrôleur plus ou moins générique gérant les formulaire ainsi
if (this->validate($this->model->getUserDataPatern(), $data)) { $this->model->saveUser($data); } else { .... }
en clair j'ai un plugin chargé de valider le formulaire au niveau syntaxique il est le seul à pourvoir le faire car contrairement au modèle il connais lui la façon don la vue lui répond. par contre le modèle lui défini l'API si sais donc ce qu'il attend la méthode getUserDataPatern va dire qu'en entrée le modèle attend deux chaine une date et un entier et c'est la méthode validate du plugin du contrôleur qui va faire la vérification e tenant compte de son environnement
il peut alors donner les datas aux modèle qui lui va pouvoir le traiter vérifier la cohérence métier des données et par exemple les enregistrer.
la méthode validate est donc très générique elle a simplement besoin de connaitre le contexte c'est a dire quel sont les type de donnée attendus pas le modèle et le format des donnée reçus par de la vue.
cela se fait dans le plugin au moment de l'initialisation
au passage on peu avoir à valider un formulaire sans pour autant le donner immédiatement au modèle
par exemple lorsque je crée un utilisateur je ne quitte pas le formulaire tant qu'il n'est pas valide lorsqu'il est validé je propose la saisie d'un ou plusieurs profils que je valide aussi
lorsque tout est ok j'enregistre le tout en une seule transaction.
pour faire ça je suis obligé de faire deux méthode une pour valider une pour enregistrer
A+JYT
Hors ligne
Pages: 1