$validators['couleur'] = array( array( 'InArray'
, array( 'bleu'
, 'vert'
, 'blanc'
, 'noir'
)
)
, Zend_Filter_Input::DEFAULT_VALUE => 'blanc'
);
$box = new Zend_Filter_Input(null, $validators);
Personnellement (pas taper), je trouve ca long, moche et surtout, il faut comprendre et apprendre le comportement de Zend_Filter_Input...
Et visiblement, ca n'a pas l'air d'avoir le comportement que l'on pourrait penser (retourner la valeur par défaut en cas de valeur pas dans la liste).
2 choses
1° Il a bien le comportement annoncé par la doc. Et moi j'ai un autre besoin. Je tente de faire entrer une responsabilité supplémentaire dans le code qui est de me fournir une valeur valide.
En fait ca n'existe pas dans Zend_Framework.
Il y a Zend_Validate_InArray qui vérifie et retourne un boolean.
Il y a Zend_Filter_Input qui sert a agglomérer des filtres et des validateurs ce qui permet de faire une boite noire, et on lui passe un tableau a valider.
Ce dont j'avais besoin c'est un Zend_Filter_InArray C'est ce que j'ai donc créé.
Zend_Filter_Input permet de donner une valeur par défaut et et Zend_Validate_InArray n'a pas une valeur de fallback
C'est à dire qu'il a une valeur en réserve si on ne donne pas de valeur, mais il n'a pas de valeur de remplacement si Zend_Validate_InArray retourne false
2° la complexité bien que notable a une raison.
Elle permet une notation plus verbeuse, parsable. C'est a dire que les filtres viennt ici dans l'exemple d'un array. Mais cet arrait pourrait venir d'une config, en ini, en db, en yaml .... Donc on peut créer un outil de génération de filtre ...
En outre Zend_Filter_Input est un peu une rustine pour ceux qui veulent utiliser des briques de Zend_Framework mais sans utiliser le mvc/application/zend_form...
Tandis que
in_array($value,array('bleu','vert','blanc','noir)) ? $value : 'blanc';
est nettement plus compréhensible en utilisant deux opérateur de base (?: et array), ainsi qu'une fonction (de base aussi) sur les tableaux (in_array)
C'est c'est en effet la version de base qu'on retrouve dans ma fonction de mon premier post.
Mais je ne veux pas de ça dans mes contrôleurs.
Quand on a 15 valeurs en entrées dans 25 contrôleurs je ne trouve plus ca aussi "compréhensible"
D'où ma première question : sachant que c'est beaucoup plus simple de NE PAS utiliser le ZF, il doit y avoir un énorme intérêt à l'utiliser.
l'idée c'est juste de forcer l'utilisation de cette normalisation par le reste de l'équipe.
Alors, si je comprend bien, on va essayer en utilisant des trucs vachement compliqués que les développeurs deviennent bon ?
Rien à voir. C'est en isolant les responsabilités qu'on les contrôle mieux.
L'objectif est bien au final de créer des validateurs et filtres maisons ayant une sémantique forte et proche des ressources qu'on utilise, développée une fois pour toute et que les développeurs n'aie qu'a l'appeler quand on leur demande de travaille avec une telle donnée.
C'est à dire
si un développeur doit faire un script qui accepte en entrée un légume, il doit pouvoir ajouter un My_Filter_Legume($monPanierDuMarché)
Ce n'est pas à lui a re définir les critères. Ils sont définis et vérifié par une boite noire donc la création a été la responsabilité d'un autre.
Donc ma conclusion, c'est ce qui existe c'est déjà bien, mais ca ne réponds pas à un besoin que j'ai et qui ne trouve pas encore de réponse dans le framework.