Discussion :

[mantex]

Bonsoir,

Je dois écrire un formulaire (questionnaire) qui utilise des données depuis plusieurs tables (sujets, contributeur, résultat évaluation..) .

Pour commencer simplement et doucement j' ai donc les opérations suivantes:

Créer un module frontend evaluation OK
Créer une instance de evaluationform OK

Pour le premier widget de mon formulaire, j' i besoin de récupérer un champs (enum) d' une autre table.

Voici le code de mon lib/form/doctrine/EvaluationForm.class.php
:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
 $this->widgetSchema['socialrelation'] = new sfWidgetFormChoice(array(
      'choices'  => Doctrine_Core::getTable('Contributor')->getSocialrelation(),
      'expanded' => true,
    ));
    $this->validatorSchema['socialrelation'] = new sfValidatorChoice(array(
      'choices' => array_keys(Doctrine_Core::getTable('Contributor')->getSocialrelation()),
    ));

J' obtiens
Unknown method ContributorTable::getSocialrelation

[Michel Rotta]

A la base des formulaires permettant les modifications il y a les objets du modèles basés sur Doctrine (ou éventuellement Propel).

Ces objets ne peuvent modifier qu'un enregistrement à la fois (quoique, mais laissons le quoique de côté).

Donc, les form ne peuvent modifier qu'une enregistrement d'une table à la fois.

Donc, ce n'est pas faisable.

Quoique (bis)...

En effet, tu peux définir, dans ton formulaire des "embed" form, qui permettent d'inclure dans un form de base (commande), d'autre form à modifier (lignes de commande).

L'autre solution, si le nombre de ligns à modifier est fixe, c'est de définir entièrement ton formulaire, non lié à une table (à partir de sfFormSymfony) et de traiter le bind et l'enregistrement directement "à la mano". Ce qui n'est pas très compliqué et permet, à ce moment là, d'utiliser certaines finesses des objets doctrines pour accéder à plusieurs objets directement (la fin du premier quoiqie..., mais en dehors du save standard d'un sfFormDoctrine).

[mantex]

Trés étonnant quand meme, c' est pas si rare d' alimenter plusieurs tables depuis un formulaire si ?

Bon sinon, le nombre d' enregistrements est fixe.

sauf oubli j' en ai 8 :

1 enregistrement table contributor (celui qui évalue)
1 enregistrement table evaluation
5 enregistrements table score (1 score par topic)
1 enregistrement table customer (id du client evalué )

Si tu as un exemple pour faire ceci.

[Michel Rotta]

Rare oui, disons peu courant. Surtout en modification. D'ailleurs, tu veux afficher les 8, modifier les 8 à la fois ou modifier certains des 8 ?

[mantex]

Non simplement création des 8 enregistrements.

C' est un formulaire d' évaluation.

J' ai pu lire ici et la qu' il fallait utiliser les embedForm pour faire cela.

http://www.symfony-project.org/more-...Advanced-Forms

En fait le visuel du form serait composé de ( bloc par bloc )

1 champs bouton radio => (choix du lien avec l evalué)
5 champs texte + bouton radio + 1 imput text => ( score + comment note)
1 champ imput text => (comment global)

[Michel Rotta]

Si tu peux avoir une liaison qui parte d'une table de base et que les autres tables y soient liées en étoiles.

Dans le genre facture (table de base), 2 adresses de livraisons, n lignes de commandes, n ligne de TVA

Tu peux alors envisager d'utiliser les embed form.

Dans le cas contraire, le plus simple est de créé un form de toute pièces et de faire les sauvegardes "à la mano"

[mantex]

Dans mon cas j' ai une évaluation qui est composé de 5 thèmes avec 1 note par theme et lié a un client qui est effectuée par un contributor .



Quand tu parles de faire le form à la mano , tu veux dire à l' ancienne en html, tu postes les variables pour les traiter ensuite ?

[Michel Rotta]

Mon symfony non !

Tu crées un objet enfant de sfFormSymfony

Tu y crée les widgets et validators nécessaire, tu lui lie, au retour, les données pour les vérifiées, si elle sont bonne, tu crées les enregistrements nécessaires. C'est dans cette dernière partie que le place le "à la mano".

[mantex]

Oui mais comment ?

Si j' utilise des widgets je vais devoir créer un objet form qui ne pourra être sérialisé dans une seule table, non ?

Comment procéder pour sauver les objets individuellement en fonction des tables avec lesquelles il sont associés.

Ex: mes 5 scores doivent être sauvés dans la table score et dans la table evaluation (1 evaluation = 5 scores par client et par contributeur) .

[Michel Rotta]

Si tu étudies un peu l'API de symfony, tu vas voir que tous les formulaires ont un ancêtre commun : sfForm. Ancêtre qui peut être utilisé indépendamment de symfony.

Ensuite vient la partie plus intégrée au framework, sfFormSymfony, qui lui est conçu pour travailler avec le framework mais pas avec une liaison base de données.

C'est lui qui est dérivé dans sfFormObject, qui descend indirectement de sfFormSymfony. Et qui va donner naissance à notamment sfFormDoctrine.

Maintenant, il y a deux manières d'attaquer les form depuis symfony (deux bonnes manières, il y en a plein de mauvaises). Dans le cas où ton formulaire est simple, et relié à une table tu as intérêt à le baser sur sfFormDoctrine et à le laisser gérer les sauvegardes.

Mais, si tu as un formulaire zarbi avec des données qui doivent être sauvegardées dans plusieurs tables, un peu partout... le plus simple est d'utiliser un form que tu crées depuis sfFormSymfony. Ou mieux, BaseForm qui est lui même enfant de sfFormSymfony.

Le widget permet d'afficher à l'écran un champ de saisie, il permet, en outre de le peupler avec des données, et, éventuellement, si un validateur est associé et en erreur, d'afficher le message d'erreur. A la base, il n'a aucune liaison avec une quelconque base de données. C'est dans le sfFormDoctrine que cette fameuse liaison apparaît. Même chose pour le validateur, qui, lui aussi, se contente de valider les donnés fournies en entrer, et, éventuellement, de retourner soit des erreurs, soit des données purifiées

Tu as donc tous les outils, avec sfFormSymfony pour créer des forms, il suffira de les sauvegarder par après, et par ton code à toi. Une doc sur les formes indépendante.

[mantex]

Oui merci pour ces explications je vais étudier un peu l' api et le lien que tu m' envoyé.

Au passage, tu sais comment afficher un widgetFormChoice (bouton radio) en ligne.

Genre comme ceci

Label1: <bouton radio> Label2: <bouton radio> Label3: <bouton radio>


Merci

[Michel Rotta]

Je me demande si, avec une simple feuille de style adapté, tu ne pourrais pas arriver à ce que tu veux.

Tu as, dans le widget, un argument qui permet de définir les propriétés html du code généré, tu lui donne un style propre. Puis, dans la feuille de style de projet, ou du module, tu lui donnes les instructions pour s'afficher en ligne.

C'est certainement la première piste que j'explorerais.

[mantex]

Oui c'est ce que je me disais également, mais j' ai vu que certains widgets pouvaient gérer cela directement ou voir directement au niveau du form.

Pour ceux qui manipulent régulièrement ces paramètres.... je suis preneur de l' info.

[Michel Rotta]

Ce ne serait pas logique au niveau du html généré. On est là exactement dans un problème d'affichage, pas de positionnement d'élément.

L'avantage d'utiliser la css en lieu et place de modifier le html généré est que, si tu changes d'avis un jour, tu pourras facilement modifier la css, voir même avoir les deux possibilités. Pas si tu verrouilles ton html.

Donc, et après réflexion, je suis convaincu qu'il faut en passer par le css.

Maintenant, c'est toi le maître de ton projet, il existe des solutions pour générer le html comme tu le veux, il suffit d'écrire le template entièrement à la main, pour chaque champs. Quoique, même là, je ne suis pas sur de ce que tu pourras sortir d'un render() sur ta liste...

[mantex]

oui mais c' un peu lourd de gérer champs par champs alors qu' un simple attribut dans le widget pourrait permettre de gérer cela surtout que finalement pour les bouton radios gérés ou les choix sont un tableau d' un seul et même widget.

Dans le cas de 5 choix par bouton radio tu fais 5 widgets individuels ?

Je suis pas rendu , mon formulaire doit comporter plusieurs de lignes de question (1 question = 1 choix sur 5 valeurs ).

[Michel Rotta]

Moi je gère dans la css, mais je crois l'avoir déjà dis...

Ceci restera mon dernier conseil sur ce sujet.

L'idée de modifier la structure du html dans ce cas me semble une mauvaise idée.

[mantex]

ok !

et si tu veux avoir sur une meme ligne :

<Bouton radio> valeur1 valeur2 valeur3 valeur4 valeur5 | commentaire

Tu es obligé de passer un embedform pour pouvoir gérer ton input text (commentaire) a côté non ?

[Michel Rotta]

Deux choses différentes

Afficher le champ : commentaire
Tous dépends d'où vient ton champ. Si ton champ est dans la table à la base du form, tu n'as pas à utiliser un embedfom.

En fait, le seul cas où je verrais l'utilité d'un embedForm c'est si ton champ provient d'une autre table, et, vu la structure que tu proposes, que cette table est liée en 1-1.

A mon avis, c'est dans la même table, donc pas de embedForm


Mise en forme du formulaire
Tu as deux choix, soit tu veux un formulaire "standard" et tu laisses le render du form générer un tableau sur deux colonnes, très banal, mais suffisant pour beaucoup de formulaires basic. Soit tu veux un formulaire plus élaboré, notamment sur 2x2 colonnes ou autre nécessités rédactionnel.

Dans ce cas, a toi de faire le template à la main, et de définir entièrement la structure de l'écran que tu souhaites, tu récupères les données de chaque champs (widget) par render(), renderLabel(), renderError(),... et tu les places un peu où tu veux sur ton écran, dans un tableau, dans un nuage de div, dans un mélange des deux.

Reste la liste, le render du widget va te la rendre pareil à avant... Il faudra toujours de la css pour la mettre en ligne. Attention, les listes de ce genre ont la particularité dans symfony d'être, généralement, rattachées à une table pour les options, il est donc facile d'ajouter une option, il faut en tenir compte dans la génération de l'écran. Autre possibilité aussi, l'écran de l'utilisateur peut être plus petit que le tient (portable, modile) ou il peut avoir changé la taille de la police, ce qui va modifier notablement le formulaire et le comportement de la liste. La aussi, des essais sont souhaitables.

[mantex]

Merci pour ces infos.

En fait il y aura 2 de types de champs commentaires:

1 par score => 1 par ligne stocké dans la table score
1 par evaluation => tout en bas du formulaire stocké dans la table evaluation.

Je rappel que dans mon cas une evaluation est composée de 5 scores et de 5 commentaires.

Le commentaire en bas sera surement optionnel et général.

[Michel Rotta]

Tu peux peut-être mettre ton shema.yml ?