Zend FR

Je n'utilise pas correctement les formulaires ? On ne le rempli/valide pas comme ça, ou bien tu parles des fieldset que je n'utilise pas ?

Je viens de regarder ce qu'était un fieldset dans ZF2, et d'après ce que j'ai compris, c'est un ensemble de champs qu'on réutilisera plusieurs fois dans plusieurs formulaires, un peu comme une classe parent pour le formulaire c'est bien ça ?

Sinon j'utilise le formulaire sur la même action, simplement je vérifie les droits et j'affiche le formulaire correspondant au niveau de droit de l'utilisateur. Peut être que ce n'est pas très correct non plus, mais je devrais dupliquer l'action en 3 fois (une pour le visiteur du profil, une pour l'utilisateur qui le modifie, une pour l'administrateur) ?

Ce qui me frustre un peu dans ZF2, c'est pas la création des formulaires en eux même, c'est que lorsque je créé un formulaire, je dois aussi créer un filtre, ajouter des lignes dans Modules.php, récupérer les filtres dans mon controller pour ensuite injecter les données dans le modèle (ce qui fait que je dois créer 2 fichiers, et dupliquer beaucoup de code pour créer un simple formulaire).
C'est d'ailleurs pour ça que j'utilise le service manager pour créer mes formulaires, un peu à la même façon que pour les modèles :
Je créé mon instance du formulaire, je lui passe l'input filter dans le service manager, puis dans le controller je n'ai qu'à récupérer l'instance du formulaire créé via le SM.

Ok je pense avoir compris, merci pour ces renseignements
Je devrais quand même créer plusieurs fichiers (un pour chaque formulaire, et un pour chaque fieldset que je récupère dans ces formulaires), mais je ne dois pas changer chaque fichier en cas de modification.

J'ai aussi vu pas mal de chose intéressantes dans la doc sur les formulaires que j'ignorais (avant je me basais sur le quickstart de ZF2 pour faire mes formulaires).

Au passage, je vois que certains mots de la doc sont en français, y aurait-il une doc française ?

J'ai vu qu'il y a des "annotations" qui permettent de centraliser la création des éléments de formulaires, les filtres etc, mais je ne comprends pas vraiment ce que c'est, ni comment on s'en sert. C'est une autre façon de créer les éléments de formulaires ?

Concernant le problème que j'avais avec l'input Date, j'ai vu en faisant un dump que les inputs avaient une propriété "priorityQueue", mais je ne trouve rien dans la doc à ce sujet, ne pourrais-je pas l'utiliser pour résoudre ce problème ? Faire en sorte que le validateur passe avant le filtre par défaut de l'élément Date ?

C'est possible d'afficher séparément chaque checkbox de l'élément multi-checkbox ? La doc montre comment afficher les autres éléments séparément, mais pas celui-ci.

Pour le 1er problème que j'avais avec "setValueOpttions", j''ai réussi à le contourner en utilisant le validateur "inArray".

Dernière modification par Seryus (03-09-2013 19:57:09)

Orkin a écrit:

Salut alors les filtres sont bien passés avant la validation ça me parait même logique puisque dans la logique si tu soumets un input qui doit être rempli avec un espace et que tu mets le filtrer StringTrim, il va d'abord retirer les espaces pour ensuite faire la validation et retourner une erreur.

Mais ça ça dépend des filtres et des validateurs. Pour les validateurs de l'élément Text je comprends qu'ils doivent s'exécuter après les filtres, par contre pour les éléments plus spécifiques comme l'élément Date, Number, etc ça me parait plus logique que les validateurs s'exécutent avant les filtres. Si tu regardes bien, lors de la validation du formulaire HTML5, il y a déjà des validateurs qui sont exécutés avant tes filtres PHP. C'est simplement qu'on peut les désactiver (car c'est coté client) ou que certains navigateurs ne le supporte pas encore.

Dans mon cas avec l'élément Date, il faut d'abord vérifier que l'utilisateur entre une date, avant d'essayer de convertir la date dans un format donné. Là le filtre passe avant, il essaie de convertir une valeur quelconque en une date, puis valide la date (alors que si le filtre est passé, on peut être sûr qu'il s'agit bien d'une date, plus besoin de mettre le validateur après). Mais si l'utilisateur n'a pas entré de date, ça lève une exception, plutôt que de lui dire "le champ attend une date au format aaaa-mm-jj".

Je pense que le composant formulaire est assez confus. Pour moi un élément de formulaire sous ZF2 n'est rien d'autre qu'un input filter avec des options. Habituellement (dans le cas des formulaires) le PHP sert à valider/filtrer les valeurs des formulaires HTML. Un formulaire en PHP n'a pas de sens.
En tournant les choses de cette façon, dans ZF2 on créé un élément de formulaire (autrement dit un ensemble de filtres/validateurs) pour ensuite lui rajouter un input filter (qui est aussi un ensemble de filtres/validateurs).
Ce serait plus simple si les formulaires ZF2 étaient de simple filtres, et qu'une aide de vue se charge de transformer ces filtres en formulaire html, en fonction des options choisies.

Par exemple :

[lang=php]
/* Création d'un formulaire (ensemble d'input filter) : */
<?php
$form = new Form();

$numberElement = new Element\Number(); // On créé le validateur "primaire" NumberFormat
$numberElement->setProperties(array( // Uniquement pour le HTML, il serait d'ailleurs plus logique de le mettre dans l'aide de vue.
    'name' => '',
    'class' => '',
    'id' => '',
));

$numberElement->setAttributes(array( // Les attributs sont des "sous validateurs"
    'min' => '', // On ajoute au validateur primaire le sous validateur LessThan
    'max' => '', // On ajoute au validateur primaire le sous validateur GreaterThan
));

$numberElement->setFilters(array( //Inutile ici mais c'est pour l'exemple
    array(
        'name' => 'Int', 
        'priority' => 1,
    ),
));

$form->add($numberElement);

/* Création du "vrai" formulaire HTML dans la vue */
echo $this->form($form);

/* qui affiche : */
?>
<input type="number" min="" max="" class="" id="" name=""/>

Cette façon me parait beaucoup plus claire, le développeur n'a pas à devoir créer les éléments de formulaire, puis créer les filtres tout est fait en une seule fois (et en plus la création de ces filtres ressemble beaucoup aux vrais formulaires HTML, on créé l'input, puis on lui met les attributs). Il y a les validateurs qui doivent s'exécuter avant tout le reste, puis les filtres/validateurs "secondaires" qui s'exécutent, en fonction de la priorité qu'on leur a donné.

Je m'éloigne un peu du sujet, mais c'est comme ça que je vois les choses

Tu peux le faire en passant par une factory à laquelle tu passes au constructeur tout ce que tu as besoin. Soit tu fais la construction du formulaire depuis le constructeur soit depuis la fonction init() (dans ce cas il faudra penser à l'appeler manuellement).

Ensuite tu créés le fieldset à la main directement dans le formulaire : $this->add(new MonFieldetset($mesparams));

Oui c'est ça ! Tu peux appeler la méthode manuellement après ton new Fieldset()

ah oui tu as raisons je t'ai dit une bêtise. Il me semble que la doc officielle en parle. Sinon tu peux essayer de retrouver la fabrique qui sert pour les fieldset et voir ce qui est fait avec le getInputSpecification()

En suivant ici ça devrai le faire http://framework.zend.com/manual/2.2/en … -extension

Implémentes la méthode getInputFilter() qui créé tes inputfilter.

En fait dans le lien il y a surtout la partie qui parle de lazy loading de l'input filter. Sinon de mémoire tu peux le rajouter dans le getInputFilterSpecification du formulaire de la manière suivante (j'ai pas testé mais ça fonctionne comme ça pour les validations group)

return array(
'nomdufieldset' => array(
'nominput' => array(...)
)
)

Seryus a écrit:

_ En essayant cette méthode de la doc qui implémente ServiceLocatorAwareInterface, je ne peux pas car mon fieldset implémente déjà une autre classe (InputFilterProviderInterface)

En faite c'était super simple, cette méthode fonctionne très bien et elle est à mon avis plus propre que celle que j'ai trouvé par la suite, j'ignorais simplement qu'on pouvait implémenter de 2 classes, en séparant chaque classe d'une virgule.
Résultat, je n'ai même plus besoin d'utiliser la fabrique, je peux simplement déclarer la classe dans "invokables" et le tour est joué.

Je me pose néanmoins quelques questions sur la fabrique maintenant. Dans ZF2 il y a le serviceManager principal, puis plusieurs autres "enfants" serviceManager. Chacun à sa propre fabrique, mais les enfants héritent des éléments du SM principal.
Dans le cas des éléments de formulaires, il y a l'enfant qui récupère sa config dans getFormElementConfig() (ajouté à partir de ZF2.1 d'après ce que j'ai pu lire).
J'ai actuellement plusieurs formulaires sur mon site, et j'utilisais auparavant le SM principal pour les déclarer dans "invokables" (dans getServiceConfig()). Ça ne serait pas mieux de les déclarer dans "invokables" de getFormElementConfig() ?
Ou bien ce n'est que pour les éléments des formulaires ? À part pour la clarté du code, il a-t-il d'autres avantages à utiliser les SM enfants ?

Je n'ai pas trouvé d'explications en détail de ces "SM enfants", ce qu'ils font de plus par rapport au SM principal, simplement des exemples d'utilisation (lors de la création de ViewHelper ou de la création d'éléments de formulaire personnalisé). Auriez-vous un lien et/ou une explication à me fournir ?

Orkin a écrit:

En effet lorsque tu vas utiliser une fabrique pour créer un formulaire le Service Locator qui t'es passé en paramètre sera en fait un FormElementManager donc si tu veux accéder à un service, à l'orm etc ... Il te faudra faire $serviceLocaror->getServiceLocator() pour récupérer celui de base.

Oui je suis tombé sur ce problème, mais en cherchant un peu je suis tombé sur un article qui expliquait en gros le fonctionnement du SM, ça dépend de l'endroit où on a déclaré la factory (getServiceConfig(), getFormElementConfig(), etc).

Orkin a écrit:

PS : Finalement tu en auras appris des choses cette semaine

Oui et encore je n'ai pas tout dit ici
J'utilisais ZF2 depuis un moment, mais en faite je ne faisais vraiment pas ce qu'il fallait. Je trouve que la doc n'est pas assez claire (on trouve en général mieux ailleurs) et elle contient des erreurs (peut être que ce sont des oublies des versions précédentes ?). Du coup je me basais (trop) sur le quickstart, qui en faite ne montre vraiment rien de l'utilisation de ZF, et ne montre pas comment bien utiliser le framework. Je savais que la flexibilité de ZF2 était à la fois son point fort et son point faible, mais j'étais loin de m'imaginer à ce point là

Je suis d'ailleurs en train de refaire entièrement mes modèles (et mon fichier Module) pour utiliser des hydrators commun pour mes modèles et formulaires, mais j'ai l'impression que ça a été rajouté très récemment (dans la version 2.2 pour cette partie par exemple) et du coup à part la doc, il n'y a rien dessus (enfin sur ce que j'essaie de faire, on peut trouver sur les hydrators en général, mais c'est vraiment bref; les gens préfèrent  se tourner vers Doctrine).

Ce qui m'amène à une autre question : est ce qu'on peut faire en sorte que notre objet resultSet hydrate un objet de la même façon que le font les formulaires (avec les relations OneToMany, ManyToMany, etc) ?
J'aimerai pouvoir hydrater une propriété du type Auteur, en hydratant mon objet Article à partir d'une requête avec jointure (et récupérer les infos sur l'auteur en utilisant par exemple $article->getAuteur()->getName()). Et tout ça en utilisant l'hydrator de ZF2 (il me semble que Doctrine le fait très bien, mais j'aimerai m'en passer pour le moment).