Solutions "merge" de 2 forms de relations n-n

**Gauldo** · 15/03/2010, 00h04

Bonsoir à tous,

Merci à tous de prendre le temps de lire mon problème. Je débute sous symfony, mais je commence à maitriser l'ensemble et résoudre les problèmes courants.

Seulement voilà, j'arrive face à un problème qui concerne les formulaires et les relations n-n (many-to-many).

Explications : Il s'agit d'un projet scolaire, et cette partie consiste à pouvoir créer des listes d'étudiants basé sur des critères d'étudiants (comme dans le publipostage). J'ai donc une table Listing et une table Optin. Optin contient la liste complète d'étudiants, et dans Listing sont les listes proprement dites (chaque étudiant peut créer ses propres listes).

Voici le shema.yml

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
57
Listing:
  actAs:
    Timestampable:
  columns:
    user_id:
      type: integer(4)
    name:
      type: string(45)
    description:
      type: clob(65535)
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
      foreignAlias: Listings
  relations:
    Optin:
      class: Optin
      local: id
      foreign: id
      foreignAlias: ListingOptins
 
Optin:
  actAs:
    Timestampable:
      created:
        name: created_at
        type: timestamp
      updated:
        disabled: true
  columns:
    fname:
      type: string(45)
    lname:
      type: string(45)
    email:
      type: string(45)
    bdate:
      type: date
    sex:
      type: integer(8)
    type:
      type: string(45)
    promo:
      type: string(45)
    status:
      type: string(45)
      default: active
    hash:
      type: string(45)
  relations:
    Listing:
      class: Listing
      local: id
      foreign: id
      foreignAlias: ListingOptins

Mes deux modules ont été "admin-générés" par Doctrine. J'ai donc mes deux formulaires et mes deux modules de crées. Je souhaiterais insérer (merge?) la liste des étudiants (Optin) avec son filtre dans le formulaire de Listing.

Le problème qui vient à moi, est que le formulaire de Listing ne convient pas puisqu'il est désactivé (on n'ajoute/supprime pas d'étudiants via cette application). Je n'ai donc aucune idée comment résoudre ce problème (ajouter la liste et le filtre + traiter le formulaire Listing avec cet ajout).

Merci à tous ceux qui prendront la peine de m'aider, c'est très apprécié.

Bien à vous tous, Bonne semaine !

**sacricri** · 15/03/2010, 09h06

Bonjour,
Je ne suis pas sûr de bien comprendre le problème...

Peux-tu expliciter un peu plus ta question en indiquant un exemple au besoin ?

**Gauldo** · 15/03/2010, 09h35

Oui en effet, à me relire, j'ai tenté d'être clair et c'est un echec total

Il était tard.

En gros, je souhaite ajouter la liste+filtre du modèle Optin avec un batch action personnalisé dans le formulaire par défault du modèle Listing.

Plus concis, est-ce plus clair ? Merci de votre aide.

**sacricri** · 15/03/2010, 11h48

hum, trop concis ?

je ne comprends pas ton histoire de liste+filtre ni ton batch action

désolé :p

**Gauldo** · 15/03/2010, 13h50

D'accord, je reprends

Quand je parle de liste, c'est ce qu'on voit dans l'admin sur l'indexSuccess.php (optin/index)
Une liste d'entrées (dans mon cas je cherche à récupérer celle de Optin) accompagné de ses filtres, toujours tels que sur indexSuccess.php (optin/admin) afin de pouvoir sélectionner (grace aux checkboxes, donc une "batch action") les optins que je veux associer à Listing (relation n-n).

Donc l'idée est d'ajouter ces deux éléments au formulaire ListingForm et de les traiter ensuite.

J'espère avoir été plus clair...

Merci !

**sacricri** · 15/03/2010, 14h25

Je vois un peu mieux

Est-ce vraiment utile de le faire dans la liste ? N'est pas plus simple de le faire directement dans le formulaire d'ajout ou d'édition avec une liste déroulante à choix multiples ?

**Gauldo** · 15/03/2010, 14h43

Je n'ai pas de contrainte à ce niveau-ci. Le seul problème est que j'ai fortement besoin du filtre car il y a plus de 500 enregistrements.

Vous auriez une solution si on prends cette option ?

Merci encore

**sacricri** · 15/03/2010, 14h55

Ok, je viens de comprendre le concept ! :p

Chaque listing créé par un étudiant comporte une liste d'étudiants. Et donc, il faut pouvoir les ajouter facilement.

Je pense qu'il va falloir faire quelque chose d'assez spécifique.
Disons dans ton formulaire d'ajout/édition de listing, tu ajoutes un champ autocomplete qui permet de rechercher un étudiant par nom/prénom, quand le nom est trouvé, tu mets un bouton à côté qui l'ajoute en ajax à une liste liste déroulante par exemple et quand c'est terminé, tu save le formulaire.

Pour l'autocomplete, je pense que ce n'est pas un soucis avec celui présent dans sfFormExtraPlugin.
Pour le reste, il faut créer un bouton qui lance une petite requête ajax qui ajoute une option dans une liste déroulante.

J'aurais sans doute été chercher de ce côté là mais je ne connais pas toutes les finalités non plus

**Gauldo** · 15/03/2010, 15h19

Arf, ça serait super sympa comme concept, mais l'idée est que les étudiants sont filtrés via des critères, il vaut mieux donc faire du traitement en "bulk" et les filtres générés par Doctrine me vont très bien pour l'instant...

Je ne sais pas si il y a moyen de récupérer ça... A ton avis, c'est plus compliqué comme ça ?

Je me sens un peu largué à ce niveau, j'ai du mal avec tout ces trucs générés automatiquement, j'aimerais mieux les maitriser...

Merci

**sacricri** · 15/03/2010, 15h24

Hum, en y réfléchissant, s'il s'agit bien d'une relation n-n, Doctrine et symfony le gère directement dans les filters. Normalement, tu dois déjà avec une liste déroulante à choix multiple dans tes filters.

**Michel Rotta** · 16/03/2010, 13h47

Si je récapitule ce que je crois comprendre

Tu as une liste d'étudiant : Optin

Tu as une liste que les étudiants doivent pouvoir choisir : Listing.

Un étudiant (Optin) peut avoir plusieurs options (Listing) et une options (Listing) peut être choisie par plusieurs étudiant (Optin).

Tu utilises sfGuard pour la gestion de la sécurité et ta table étudiant est liée à la table user de sfGuard.

Les choses que je ne comprend pas ou qui me semble bizarres

Tu as deux tables dans ton modèle, hors pour une relation n-n il en faudrait trois.

Tu as deux fois la déclaration "relations" dans la table "Listing" ce qui n'est pas conforme au format de fichier.

La relation "Optin" de la table "Listing" ne peut pas fonctionner.

Tu as une option "sex" dans la table "Optin" mais pas dans la table "Listing", ce qui ne permettra pas de vérification (ni de filtre) lors des propositions.

La relation "Listing" de la table "Optin" ne peut fonctionner tel quel.

Les choses auquel il faudrait faire attentions

Dans la table des étudiants (Listing) tu as un champs libre Descriptions qui n'a aucune chance d'être accepté par la CNIL, trop libre pour la saisie de n'importe quels informations.

Les questions qui pourraient orienter le fonctionnement et le développement de l'application

Qui doit inscrire les étudiants aux options ? Eux ou un externe ?

Comment les vérifications des inscriptions, les validations des inscriptions doivent-elle être gérée.

As-tu fais MLD des données ?

Quels sont les modifications que tu penses apporter (ou que l'on va te demander) l'année prochaine ?

La où cela va ce compliquer

Doctrine gère bien les relation n-n, regarde sur le site de Doctrine, ou revient ici et explique un peu mieux ce qui doit être lié entre les deux tables (au cas où cela ne serait pas une vrai n-n) et on fait le schema ensemble.

Il existe trois outils automatique pour gérer ces liaisons n-n, mais aucun ne permet de gérer les choix ou l'auto complétion. Il faudra donc faire un outils spécifique avec des formulaires "embeded".

**Gauldo** · 18/03/2010, 09h09

Bonjour,

D'abord un grand merci d'avoir pris le temps d'analyser mon problème. Désolé pour la réponse en différé mais j'ai manqué de temps...

Il y a quelques petites choses qui sont mal comprises, je dois pas être doué pour expliquer

Voici plusieurs points :

La table Optin n'est pas utilisée avec sfGuard, elle sert uniquement pour créer des "Mailing List" de publipostage. (On gère l'inscription des étudiants d'une autre façon, il ne sert à rien d'en parler dans ce cas ci)
La table Listing sont des listes (comportant une liste indéfinies "d'Optins") que les utilisateurs peuvent créer à leur gré.
La description que l'on trouve dans Listing, correspond donc à la description de la liste, et non d'un Optin particulier ! (Exemple: "Liste d'étudiants de sexe féminin participant au bureau des sports")
La table Optin est remplie en début d'année scolaire, et elle reste relativement stable
Dans mon shema, j'ai une relation n-n qui est prise en charge par Symfony et qui crée automatiquement la table de liaison, cette table qui est bien présente dans mon MLD.

Donc en gros, ce qui semble abstrait c'est la table Listing, qui sert à l'utilisateur (sfGuard et non pas Optin) à créer ses propres listes (Listing) d'étudiants (Optins). Même si l'utilisateur est étudiant, il n'a rien a voir directement avec Optin.

J'espère que c'est plus clair pour vous, merci beaucoup de m'aider là dessus.

Cordialement

**Michel Rotta** · 18/03/2010, 23h07

Plus je lis et moins je comprend.

Un utilisateur(élève) peut créer plusieurs liste d'optim...

Et avec ton schéma Doctrine crée tous seul une troisième table pour la liaison ....

Ca il faut que je le test, vu que j'écris un article sur les liaisons N-N si la table de liaison est capable de s'auto créer, je peux réécrire la moitié de l'article !

A priori, la seul solution c'est de faire les formulaires à la mains.

Mais il faudrait commencer par un schéma de modification du genre

Initialisation de l'étudiant
Choix par l'étudiant de sa liste qu'il souhaite modifier
Affichage de la liste avec les options choisie pour cette liste et des cases à cocher pour supprimer une/plusieurs des options choisies
Un bouton ajouter qui va donner une liste (avec un pager) des optim et des case à cocher pour les inscriptions. Sur cette liste, tu rajoutes un formulaire de tris qui va permettre de mettre des critères et de trier la liste des optims pur trouver celui que l'on veut ajouter à la liste.

Dans un deuxième temps, tu peux envisager de l'ajax pour accélérer la mise à jour de la liste des optims et les ajouts.

Mais avec l'automatisme, faut pas rêver, ça ne va jamais marcher.

**Gauldo** · 18/03/2010, 23h49

Bonsoir,

Merci de votre réponse rapide. Je confirme que symfony m'a bien crée un 3ème modèle.

Je crains donc de bien devoir le créer à la main. Simplement, j'aurais bien voulu m'inspirer de ce que symfony a généré pour le modèle Optin (liste des optins donc, dans le executeIndex du module) sauf que je n'y comprends pas grand chose (beaucoup trop d'héritage, tout en cache... on s'y perds vite !). Symfony propose déjà les filtres nécéssaire...
Sinon, j'envisage peut-être supprimer les actions du formulaire (_edit, _delete, _new...etc) et créer une nouvelle action ?

Si vraiment je ne trouve pas de solution, je vais donc créer à la main.

Merci encore !

**Michel Rotta** · 19/03/2010, 16h34

En fait les formulaires d'admins sont vraiment à réserver pour l'administration et ne sont pas adapté à une utilisation plus guidée pour des utilisateurs.

Je pense que faire le tous à la mains me semble une bonne idée.

Ou trouver quelqu'un pour te le faire faire....

Doit bien y avoir des étudiants dans ton truc, un TP un peu spécial

Solutions "merge" de 2 forms de relations n-n

Symfony PHP

Partager

Partager