Discussion :

[mantex]

Voici un extrait.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
Contributor:
 actAs: { Timestampable ~ }
 columns:
  name:          type: string(255)
  firstname:     type: string(255)
  company:       type: string(255)
  job:           type: string(255)
  email:         type: string(255)
  lang_id:       type: integer(1)
  customer_id:   type: integer(7)
  socialrelation:
                   type: enum
                   length: 30
                   values: ['Hierarchie', 'Pair', 'Collaborateur', 'Exterieur']
  commnent:      type: string(255)
  address1:      type: string(255)
  address2:      type: string(255)
  postcode:      type: string(255)
  city:          type: string(100)
  country:       type: string(100)
 
Invitation:
 actAs: { Timestampable ~ }
 columns:
  token:          type: string(255)
  recall_date:    timestamp
  contributor_id: type: integer(7)
 
Lang:
 
 columns:
  name:          type: string(50)
  iso_code:      type: string(5)
 
Evaluation:
  actAs: { Timestampable: ~ }
  columns:
   contributor_id:  type: integer(7)
   expires_at:      timestamp
   customer_id:     type: integer(7)
   lang_id:         type: integer(1)
   invitation_id:   type: integer(74)
   comment:         type: string(255)
 
Topic:
 columns:
  name:         type: string(100)
  lang_id:      type: integer(1)
 
Score:
 columns:
  value:         type: integer(1)
  topic_id:      type: integer(1)
  evaluation_id: type: integer(7)
  comment:       type: string(255)

[mantex]

Bon alors j' ai modifié mon schéma.. je reprends par les bases..

Je passe juste un des champs du modèle (comment) , j' active le validateur pour ce champs.

Et la j' obtiens un

500 | Internal Server Error | sfValidatorErrorSchema
Unexpected extra form field named "id".

J-48 et je repasse mon schema sur une seul table..

[mantex]

En unsettant le champs 'id' l' enregistrement est bien sauvé..

Encore une première tous mes autres formulaires je m' occupe jamais de ce champs..

Reste à gérer les relations avec l' autre table... on se motive..

[mantex]

En suivant l' exemple suivant qui a l' air clair et surtout similaire à mon cas (relation 1-many), je vais ptete reussir à m' en sortir, non ?

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

La nuit porte conseil, paraît t -il

[Michel Rotta]

Tu as aussi un plugin qui peut être intéressant : ahDoctrineEasyEmbeddedRelationsPlugin il pourra te permettre, peut-être, de t'approcher de ce que tu recherches.

Bonsoir,

Tu crois que ce plugins peut m' aider pour mon cas ?

http://www.developpez.net/forums/d99...e-multi-table/

Non.

Dans ce cas très particulier, je reste convaincu que le form indépendant est la meilleur solution.

Mais je peux me tromper...

[mantex]

Oui en y réfléchissant et en regardant les exemples utilisant les embededform,
on constate cela peut etre être intéressant pour ajouter des items supplémentaires ou compléter un objet déja existant.

Ce que je veux faire, n' est pas cela. Mon formulaire sera certainement utilisé une seul fois par une même personne pour effectuer toujours la même tache.

1: évaluer une personne sur 5 thème (1 thème = note + 1 commentaire par ligne)
2: Mettre un commentaire général sur l' évaluation.

Et basta..

Idèalement le formulaire sera sauvegardé pour être finalisé ultérieurement
mais sa structure est figé.

Comme j' ai simplifié mon shéma récemment, n' est il pas possible d' utiliser des partials utilisant chacun 1 objet correspondant à mes tables.

1 objet pour stocker les notes + comment (table score)
1 objet pour stocket le commentaire global et les info de l' éval (invitation_id, created_at, updated_at.....


Si oui par ou commencé ?

La doc sur les embedform parle d' un tableau principal (evaluation) contenant un sous tableau de score dans mon cas. Faut il utiliser cette technique ?

Merci de votre aide.

[Michel Rotta]

Au risque de me répéter

"Dans ce cas très particulier, je reste convaincu que le form indépendant est la meilleur solution."

[mantex]

Concrètement un form indépendant cela donne quoi ? j' ai plusieurs objets donc à traiter donc je ne sais pas trop comment ni ou intervenir.

[Michel Rotta]

Il faut créer un nouvel objet dérivé de sfFormSymfony dans lib/form

Il faut y implanter une méthode configure pour créer les widgets à utiliser et les validateurs qui vont bien.

Il faut déporter le code de sauvegarde dans le contrôleur et dans les objets du modèle.

Au départ, tu l'alimente par un tableau a remplir.

C'est un peu plus lourd, mais tellement plus souple.

[mantex]

ok merci mais j' ai abandonné la solution du multitable.. J' ai ajouté des champs à ma table evalution. Simple efficace.. rapide..

J' ai passé trop de temps sur ce point qui est inexplicable au client.

Passer 1 semaine pour un formulaire de saisie.. .ce sera pour un autre projet, si tu as de la doc sur le sujet, je suis preneur.

merci encore.

[Michel Rotta]

Sur les forms et validateurs et autres widget, un bon début (hors Jobeet) est ici : http://www.symfony-project.org/forms/1_4/en/

[mantex]

Oui j' ai déja parcouru cette doc, mais mon cas semble être un peu moins bateau. En effet si on souhaite générer un formulaire pour alimenter plusieurs table relié entre elles.


D 'ailleurs un exemple, j' ai entete tres courant :

un formulaire de commande reliant des produits à un client avec saisie de l' adresse de facturation .... archi courant.. avec symfony à éviter si on veut pas exploser les délais.

Dsl mais cette doc m' aide pas du tout.

[Michel Rotta]

C'est la plus abordable (et la seule) pour expliquer le fonctionnement des sfFormSymfony et autres form dérivé.

Je connais beaucoup de développeur (dont moi) qui seraient très surpris d'apprendre que symfony n'est pas adapté à une simple saisie de commande...
Mais je suis ouvert à la démonstration de la chose (attention, je vais avoir des contre exemple lourds et indigestes )

[mantex]

J' ai quand même besoin de récupérer la valeur d' un champs défini dans une autre table.

Idéalement ce champs peut être modifiable par celui qui saisie formulaire.

J' avais pensé à cela mais j' ai un undefined call membre.

Code :

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

1
2
3
 
 
 $this->widgetSchema['hierarchie']    = new sfWidgetFormDoctrineChoice(array('model' => 'Contributor', 'expanded' => true, 'choices' => getSocialrelation());

JE vais essayer en ecrivant une fonction dans ma classe evaluation qui récupère la valeur du champs 'socialrelation' dans la table contributor.


Au moins j' aurais l' info dans le formulaire. .. j' espère !

[Michel Rotta]

L'idéal est de créer la méthode dans l'objet du modele de la table ici contributor et de retourner, au moins, l'id.

Sauf que l'id n'est pas très parlant, donc, récupère aussi une information plus parlante (genre un nom) et tu la retourne par __toString() qui est appelée pour afficher le contenu de l'objet dans la liste.

C'est un système simple et qui marche très bien.

Ne pas oublier le validator qui utilisera la même méthode pour vérifier que la valeur saisie est autorisée.

[mantex]

En fait la valeur de ce champs est de type enum et affiché sous forme de bouton radio comme je le mettais dans le dernier message.

Pourrai je appeler ma fonction (getSocialrelation()) définie dans le modèle contributor depuis la définition du widget du formulaire evaluation ?

Enfin comment lié tout ceci avec le reste de mon formulaire qui lui est pure "evaluation", j' entends par la, les autres champs saisies sont ceux de la table evaluation.

[Michel Rotta]

S'il y a bien un champ que je n'aime pas du tout, c'est tout ce qui est enum... Dans tous les cas, un modèle ainsi défini n'est plus conforme aux formes normale. En plus il oblige à répéter les données dans le modèle pour pouvoir faire des listes... Une bonne vielle clef sur une table de paramètre, au pire, une clef sur un tableau dans l'objet, c'est bien plus solide.

Ton champ dont tu dois : "récupérer la valeur d' un champs défini dans une autre table"

Il est bien dans la même table que les autres champ du formulaire ?

[mantex]

Oui je sais mais cela permet de fermer parmi une liste de valeur, ce champs n' est utilisé que 2/3 fois maxi

C' est facile à modifier , donc voila...

Et pour répondre à ta question, il ne fait pas partie de la même table que les autres champs.

Pour résumé:

J' ai finalement un formulaire d' evaluation affichant les champs de la table evaluation et 1 champs socialrelation d' une autre table, la table contributor.


En gros ce que je veux en affichant le formulaire evaluation, le contributor invité par un client affiche les champs pour saisir d' une evalutation.

Le champs socialrelation a été fixé par le client lorsqu' il a crée la fiche de son contributor.

Le champs socialrelation dans le formulaire permettra donc de confirmer ou de modifier si possible cette 'relation sociale' qui la avec le client qui l' a invité à l' évaluer.

Voilou , je ne sais pas si c'est plus clair maintenant.

[Michel Rotta]

Oui je sais mais cela permet de fermer parmi une liste de valeur, ce champs n' est utilisé que 2/3 fois maxi

C' est facile à modifier , donc voila...

C'est une illusion. A la longue, ce type de champ ne peut que corrompre une application.

Et c'est loin d'être simple à modifier, il faut modifier le shema de la base, modifier la base et modifier le modèle pour avoir un tableau à jour. Trois modifications. Ma solution est largement plus simple. Un champ integer(2), un tableau dans le modèle avec les différentes valeurs possible, une méthode qui, depuis le tableau et depuis la valeur de l'integer retourne la contre partie. Et pas de répétitivité dans la table (forme 4 si mes souvenirs sont bon).

Mais, c'est ton application, tu fais comme tu le sens... Ce n'est que mon avis.

Voilou , je ne sais pas si c'est plus clair maintenant.

J'espère !

Je vois deux possibilités.

Une, on part d'un formulaire vierge non rattaché à doctrine et un enregistrement, s'il est valide, on récupère les données dans le contrôleur et on les envoies aux deux objets. (bof)

Vu que tu as déjà cassé ton modèle (qui à mon avis était meilleur) et brisé les formes normales pour tous mettre dans un enregistrement, je ne pense pas que cela puisse te plaire.

Le problème est que l'autre solution est un peu plus difficile à mettre en œuvre, je ne suis même pas sur qu'elle soit réalisable. L'idée est de rajouter ton champ à ton modèle et de surcharger la méthode save de l'objet pour récupérer un objet socialrelation a modifier ou créer, puis, transmettre les données moins celle sauvegardé juste avant à la méthode parent pour sauvegarder l'objet.

Personnellement je tenterais bien la deuxième, mais avec un rien de peur sur la probabilité de réussite. La première est moins satisfaisante intellectuellement, mais elle permettrai de revenir à un modèle de données plus sains et est plus simple à mettre en œuvre.

Comme pour au dessus, c'est toi qui pilote, j'essaierais d'aider quelque soit ton choix.