Schéma, Many To Many & champ dans la table lien

Bonjour.

Je suis actuellement sur une application dans laquelle j'ai un objet qui a une ou plusieurs caractéristiques. Une caractéristique peut être associé à 0 ou N objet. Je suis donc dans le cadre d'une relation Many To Many.
Cependant, lors de la mise en place de cette relation, on peut ajouter un commentaire sur le lien entre un objet et sa caractéristique.

Le morceau de schéma correspondant est le suivant :

Code:

---

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 58 59 60 61 62 63 64 65 66 67 68 69 70 71

Objet: connection: doctrine tableName: objet columns: idobjet: type: integer(4) fixed: false unsigned: false primary: true autoincrement: true ... relations: MetEnOeuvre: local: idobjet foreign: idobjet type: many cascade: [delete]   Caracteristique: connection: doctrine tableName: caracteristique   columns: idcaracteristique: type: integer(4) fixed: false unsigned: false primary: true autoincrement: true ... relations: MetEnOeuvre: local: idcaracteristique foreign: idcaracteristique type: many   MetEnOeuvre: connection: doctrine tableName: met_en_oeuvre columns: idobjet: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false idcaracteristique: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false commentaire: type: string() fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: Objet: local: idobjet foreign: idobjet type: one onDelete: CASCADE Caracteristique: local: idcaracteristique foreign: idcaracteristique type: one onDelete: CASCADE

---

Dans le formulaire de l'objet je voudrais pouvoir sélectionner les caractéristiques liées (par une checkbox) et que j'ajoute le commentaire pour chaque caractéristique que je coché.

Je n'ai cependant pas besoin d'avoir cela dans le formulaire de caractéristiques.

Note : le commentaire va être amené à être internationalisé.

Après quelques recherches j'ai cru comprendre que pour avoir les caractéristiques dans le formulaire je pourrais ajouter une relation dans la description de Objet :

Code:

---

1 2 3 4

Caracteristiques : foreignAlias: Objets class: Caracteristique refClass: MetEnOeuvre

---

Mais je ne vois pas comment intégrer le commentaire.

Une idée ?

Le shema corrigé.

Code:

---

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

Objet: connection: doctrine tableName: objet columns: ... relations: Caractéristiques: class: Caracteristique refClass: MetEnOeuvre foreignAlias: Objets   Caracteristique: connection: doctrine tableName: caracteristique columns: ...   MetEnOeuvre: connection: doctrine tableName: met_en_oeuvre columns: objet_id: type: integer primary: true caracteristique_id: type: integer primary: true commentaire: string(255) relations: Objet: onDelete: CASCADE foreignAlias: MetEnOeuvres Caracteristique: onDelete: CASCADE foreignAlias: MetEnOeuvres

---

• on laisse doctrine créer les clefs primaire lui même, elle s'appeleront "id" de type "integer"
• les clefs de liaison on comme nom, le nom de la classe plus "_id" (si c'est possible).
• pas de valeurs par défaut dans le schéma, cela l’alourdi pour rien
• La liaison ne se déclare que sur une classe, dans le cas d'une relation 1-n, sur la classe n. Pas de paramètres par défaut, il ne reste que le foreignAlias (nom de la relation vue par la classe de l'autre côté de la liaison et, éventuellement, le onDelete.
• Création d'un lien directe entre objets pour récupérer ces "caracteristiques" (a noter le "s" qui indique dans une relation l'arrivée de plusieurs enregistrements) et son opposé entre caracteristique qui peut avoir plusieurs "objets". Ce lien skip la possibilité du commentaire quant on l'utilise, ce qui n'est pas obligatoire mais peut servir.
• type string, toujours mettre une taille

Attention, pour doctrine, malgré le lien n-n défini ici sur objet ceci n'est pas vraiment considéré comme une liaison n-n mais plutôt comme trois tables avec des liaisons &-n. Doctrine ne sait pas gérer les attributs sur une liaison n-n.

Citation:

---

Dans le formulaire de l'objet je voudrais pouvoir sélectionner les caractéristiques liées (par une checkbox) et que j'ajoute le commentaire pour chaque caractéristique que je coché.

---

Ceci n'est pas possible avec les outils de base, il faudrait le faire à la mains et cela risque d'être conton. Regarde plutôt du coté du plugin ahDoctrineEasyEmbeddedRelationsPlugin.

Citation:

---

Note : le commentaire va être amené à être internationalisé.

---

Serte. Mais cela nécessite une modifications subtentiels des objets (je suppose que objet et le commentaire dans caracteristique seront aussi internationalisé) et de la manière de les gérer et de les utiliser dans les contrôleurs et les templates. Il n'est donc pas possible de considérer que ceci "va être amené". Il faut le faire avant de commencer ou jamais.

Citation:

---

Mais je ne vois pas comment intégrer le commentaire.

---

Normale, ce n'est pas possible... (cf: plus haut)

1ère impression :
:scarymov::arf:

Merci pour tous ces infos et conseils, j'en ai bien pour la semaine :p

Citation:

---

Citation:

---

Note : le commentaire va être amené à être internationalisé.

---

Serte. Mais cela nécessite une modifications subtentiels des objets (je suppose que objet et le commentaire dans caracteristique seront aussi internationalisé) et de la manière de les gérer et de les utiliser dans les contrôleurs et les templates. Il n'est donc pas possible de considérer que ceci "va être amené". Il faut le faire avant de commencer ou jamais.

---

Les caractérisitques et objets sont déjà internationalisés, je n'ai simplement pas copié le code correspondant.

Je vais essayer de mettre en oeuvre tout çà. Je vous tiens au courant. Merci déjà.

L'internationalisation implique l'usage du behavior i18n qui modifie un peu le shema.yml et beaucoup le modèle physique qui va en découler.

Cette modification implique une vue très différente de ce qu'implique ta première question sur les modifications des liaisons. En fait, je pense que cela implique de repenser l'approche de cette partie de l'application. Essentiellement le scénario de modifications (CRUD) des "MetEnOeuvre" sur un "objet".

Citation:

---

En fait, je pense que cela implique de repenser l'approche de cette partie de l'application. Essentiellement le scénario de modifications (CRUD) des "MetEnOeuvre" sur un "objet".

---

Qu'entendez-vous par là ? Pour moi la seul différence sera le formulaire embarqué, qui comportera les champs internationalisés.

Si tu comptes ajouter un commentaire, il faudra l'internationaliser...

Ce qui implique un form embarqué dans le form embarqué. Ce qui n'est pas viable.

Cela se passera uniquement du côté du backend.

Je trouve çà curieux, je ne dois pas être le seul à faire ce genre de chose. Contrairement à des choses que j'aurais pu faire avant, cela ne me semblait pas "hors-normes".

Ce n'est pas hors normes, c'est juste hors de portée du form et de l'embed form :D

Mais c'est réalisable, à la mains...

Ce n'est pas envisageable avec de module d'admin auto générés.

Il faut se faire le form d'édition à la main et le form du commentaire à la main.

A vue de nez, je me dis que, le plus simple pour que cela marche, serait de passer par un code ajax.

Bon, ben je crois qu'il faut vraiment que je mette les mains dans le cambouis donc.
Admettons que le résultat que je veuille obtenir soit cela :

]http://img94.imageshack.us/img94/1394/screenexw.jpg

J'ai créé un formulaire nommé CaracteristiquesLieesForm qui hérite pour l'instant de sfForm.
J'envisage par la suite d'intégrer ce formulaire au formulaire principal.
Pour créer ce formulaire je pense récupérer la liste de toutes les caractéristiques et pour chaque créer une checkbox, un champ de commentaire (qui est internationalisé donc en gros un embedI18N).
Quand la checkbox est cochée, la zone de commentaires est affichée.

Comme je suis grand débutant dans Symfony et que je n'ai pas vraiment trouvé de doc sur la personnalisation à ce point de formulaires, j'ai des milliers de questions. Et pour tout dire, çà me fait peur ! :roll:. Je n'en poserais que quelques unes :

1) Si je définit les champs de formulaire dans la classe du formulaire, où puis-je personnaliser son affichage ?

2) Où définir les choses à faire lorsque le formulaire est sauvegardé ?
Autrement dit
->vérification des champs (par des simples validateurs je pense)
-> insertion des enregistrements dans la BDD

3) Où initialiser mon formulaire et pré-remplir les champs après une requête sur ma base ?

Si vous connaissez un bon tuto pour faire tout çà ou quelques éléments de réponse, je serais vraiment intéressé !

Merci déjà.

Le problème est de commencer à développer une "grosse" application avec des connaissances minimes. Il faut prendre en compte l'apprentissage d'un framework et de la POO "a fond" dans le temps de développement. Et tu as de la chance, avec la v1, c'est moins lourd qu'avec la v2 qui n'est pas encore stable et ou ce que tu as compris un jour n'est plus nécessairement vrai une semaine après :aie: Cela ira mieux une fois le framework v2 stabilisé.

Pour en revenir a tes questions, j'ouvre le bal avec une a mois.

Question 0 : ton champs commentaire sera-t-il internationalisé et, si oui, où comptes tu saisir les commentaires internationalisés ?

Question 1 : Le formulaire (dérivé de sfForm) gère la préparation des codes de base des champs (widget) et le contrôle de validité des réponses de l'utilisateur (validator). Sa gestion de l'affichage n'est que limité et optionnel. L'affichage est, lui, géré dans le template où il peut être très largement personnalisé (disons 99,99%) (avant que tu tombes sur le 0.01% tu as de la marge, je ne l'ai jamais bu) (quoique, avec ta chances... :lol: ).

Question 2 : Elle est plus vaste que la première. Pour la première partie, tu y as répondu. Pour la deuxième cela dépend. En général on va utiliser un sfDoctrineForm (qui est dérivé de loin de sfForm) et qui s'occupe en plus de ce que fait le sfForm de la partie sauvegarde d'un enregistrement. Éventuellement et dans certaine circonstances d'un enregistrement et d'enregistrements qui lui sont directement liés (liaison 1-n ou 1-1). Dans les cas extrêmes (et tu risques de passer par là en fonction de la réponse à la question 0) tu seras obliger de mettre du code dans le contrôleur et le modèle pour faire toi même la sauvegarde. C'est un des avantages de symfony, il est très souple et il y a toujours moyen de faire trouver une solution.

Question 3a : Le contrôleur est le centre d'activité de ton application, c'est lui qui initialise le form.

Question 3b : C'est plus compliquer et vas dépendre de ce que tu pourras faire à la question 2. Si tu peux avoir un form lié à doctrine, il suffira de passer l'objet doctrine au form. Si non, il suffi lors de l'initialisation dans le contrôleur de préparer un array et de le passer au form. Rien de bien compliqué.


Par contre, je ne sais pas si tu as pris le temps de faire le tutoriel JobeetJob. Si tu ne l'as pas fait, je te recommande fortement de t'y atteler, tu vas y aborder 80% des problèmes liés au développement, les problèmes les plus courants. Tu pourras alors te consacrer aux problèmes rares et spécifiques à ton application.

Merci beaucoup d'avoir répondu à toutes ces questions si rapidement.

Trèves de questions, je vais apporter les réponses :D

Citation:

---

Question 0 : ton champs commentaire sera-t-il internationalisé et, si oui, où comptes tu saisir les commentaires internationalisés ?

---

La saisie du champ internationalisé se fera au même endroit. En gros un champ commentaire de plus pour chaque langue.

Citation:

---

Question 1 : [....] L'affichage est, lui, géré dans le template où il peut être très largement personnalisé (disons 99,99%) (avant que tu tombes sur le 0.01% tu as de la marge, je ne l'ai jamais bu) (quoique, avec ta chances... ).

---

J'ai pû effectivement lire à propos de cela, mais je me demandais quel template créer et ou çà car au niveau des templates admins je suis un peu perdu. Et savoir s'il était possible de faire un template juste pour le sous formulaire qui lui sera inclus, un peu comme un partial dans le formulaire principal.

Citation:

---

Question 2 : ...

---

Voilà, le problème c'est que tout çà sera lié à MetEnOeuvre mais les éléments du formulaire ne seront pas forcément des propriétés de la table.
La checkbox sera la signification qu'il faut ajouter une entrée (ou la supprimer), il n'y aura pas de champs d'idObjet car cela sera l'id de l'objet que l'on passera depuis le formulaire principal ni de champ idCaracteristique.

Citation:

---

Question 3a : Le contrôleur est le centre d'activité de ton application, c'est lui qui initialise le form.

---

Quand vous dites "contrôleur" vous parlez bien du fichier d'actions ?

Citation:

---

Par contre, je ne sais pas si tu as pris le temps de faire le tutoriel JobeetJob. Si tu ne l'as pas fait, je te recommande fortement de t'y atteler, tu vas y aborder 80% des problèmes liés au développement, les problèmes les plus courants. Tu pourras alors te consacrer aux problèmes rares et spécifiques à ton application.

---

Si si, c'est la première chose que j'ai faite, je m'en suis même servi pour l'installation :p (Comment çà "ben on dirait pas..." ? :mrgreen:)
J'ai aussi jeter des coups d'oeil sur les tutos du genre "allez plus loin", "les formulaires", etc. Je me suis d'ailleurs dépatouiller de pas mal de trucs grâce à eux. Ils sont très bien faits.
Du coup, tout ce qui rentre dans le cadre des bases maintenant c'est bon, je gère (enfin presque hein ^^). Le souci c'est que vu que Symfony est "magique" pour toutes les choses communes, dès que l'on sort des clous ouïe ouïe ouïe. Et quelque chose qu'on aurait fait simplement avec 4 lignes de codes, se retrouve écrite en 2 lignes certes mais encore faut-il savoir où les mettre :lol:

Je suis conscient que tout ceci n'est pas simple et je ne pourrais pas apprivoiser symfony en 15 jours mais une fois que j'aurais compris comment toute la mécanique interne fonctionne, alors ce sera beaucoup plus simple de programmer mes trucs tordus :roll:

Préambule sur les formulaires de backend.
C'est une notion qui n'existe pas dans symfony mais que l'on retrouve souvent dans ce forum, hélas. Il n'y a pas de différences entre les différentes applications d'un projet, frontend, backend, turlututu et autres applications sont toutes identiques en tous points de vue et tous modules créés dans l'une peut parfaitement l'être dans l'autre.

La confusion se fait, en général, au niveau des modules auto-généré appelés abusivement module d'administration et relégué a tort au backend. Ces modules peuvent parfaitement être utilisé dans n'importe quel application d'un projet et surtout il est possible d'utiliser n'importe quel module dans le backend, qu'il soit auto-généré ou pas.

Il faut aussi prendre en compte que les modules auto-générés ne sont pas conçu pour travailler sur plusieurs entités (classe du modèles) en simultanés. Ils donnent toute leur puissance dans le cadre une classe du modèle (entité) un module auto-généré. Les liaisons 1-n vers des propriétés sont relativement simple a gérer (par des select) les liaisons n-1 à un niveau sont souvent problématique. Les liaisons qui suivraient le n-1 sont toujours difficile voir impossible à implémenter. Ceci dans le cadre d'un module auto-généré.

Question 0 :

Citation:

---

La saisie du champ internationalisé se fera au même endroit. En gros un champ commentaire de plus pour chaque langue.

---

Alors il n'est pas possible de le faire en automatique. Il faudra créer un ensemble "manuellement".

Il faut se poser la question "que deviennent les commentaires si une liaison est supprimée ?".

Je vois plusieurs solutions possibles :

• Un form standard va être difficile à gérer notamment du au fait que les champs de saisie des commentaires n'existent pas, ce qui va obliger à ré-afficher à de nombreuses reprises le formulaire.
• On peut envisager un form standart avec une couche de javascript qui n'ouvre la visibilité des champs commentaires que pour les champs cochés.

Il reste a traiter au retour les commentaires sur des liens désactivés. De plus le formulaire risque de devenir difficilement lisible si le nombre de caractéristiques augmente ainsi que le nombre de langue.
Il reste des solutions qui s'éloignent de ce que tu souhaites mais qui devraient être plus viables :

• La création d'une zone "commentaire" traitée en ajax. Quant un commentaire est actif, la zonne apparaît en dessous (chargée par javascript) et est modifiable. Les modifications des coches et des commentaires sont envoyés directement par javascript à symfony.
• Plusieurs variables sont possible notamment en passant par des boites de dialogues créées en javascript.
• A côté de chaque lien (voir de chaque lien coché avec un peu de javascript) apparaît un bouton commentaires qui ouvre une autre fenêtre pour l'édition des commentaires de ce lien. Plus proche de symfony, cette solution est surement une des plus simple à implémenter.
• Une saisie en deux temps, saisie des liaisons dans un premier temps puis, après validation des liaisons, on affiche un deuxième formulaire avec les commentaires. Ceci devrait être relativement simple à implémenter et fonctionner sans javascript sur le poste utilisateur.

Il existe certainement d'autres solutions.

A toi de voir. Commence peut-être par implémenter d'autres CRUD plus simple avant d'en venir à celui-ci.

Question 1 :
c/f le préambule.
Il n'est pas possible de ne faire un template que pour la partie embed.
Il est possible de modifier les templates dans un module auto-généré, ce qui limite alors largement l'intérêt d'un module auto-généré. Et, ici, le module auto-généré n'est pas possible...

Question 2 :
Traité dans la 1 et le préambule

Question 3a :
On est dans le cadre d'un développement en MCV avec symfony. Le contrôleur est la colonne vertébrale de l'application, une grande partie du contrôleur est traité d'une manière transparente par symfony (les routes, les objets sfRequest, les filtres,...) la partie visible pour le développeur est le fichier apps/<nomApplication>/modules/<nomModule>/actions/actions.class.php

Citation:

---

Et quelque chose qu'on aurait fait simplement avec 4 lignes de codes, se retrouve écrite en 2 lignes certes mais encore faut-il savoir où les mettre

---

C'est un des inconvénient (et des avantages une fois maîtrisé) de ce type de framework. Heureusement qu'il y a des formus !

Merci beaucoup pour cette piste de solution, je vais essayer de me lancer dans la programmation de cela.

Enfin, je vais surtout d'abord chercher par où commencer :D

Croyez-vous qu'il serait possible de créer un formulaire qui pourrait représenter la relation entre les deux.
Ce formulaire pourrait ou non hériter de sfFormDoctrine.
A la sauvegarde du formulaire je pourrais vérifier les champs, et créer un nouvel objet MetEnOeuvre qui serait inséré dans la base ?

EDIT : petit problème à l'internationalisation de cette table de lien.
Le champ idcompetence reste à 0 dans la table de translation ce qui fait que j'ai des erreurs de duplication d'entrée.
Y a t-il des choses à préciser dans le behavior dans de tel cas ? J'ai cherché mais aucune propriété ne semble convenir.

Voic mon bout de schéma :

Code:

---

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

MetEnOeuvre: connection: doctrine tableName: met_en_oeuvre actAs: I18n: fields: [commentaire] columns: idobjet: type: integer(4) primary: true autoincrement: false idcaracteristique: type: integer(4) primary: true autoincrement: false commentaire: type: string() notnull: false relations: Objet: local: idobjet foreign: idobjet type: one onDelete: CASCADE Caracteristique: local: idcaracteristique foreign: idcaracteristique type: one onDelete: CASCADE

---

Je sais que ce schéma devrait s'écrire plus proprement, ce problème peut-il venir de là ?

Le bout de schéma que tu donnes me laisse penser qu'il ne peut pas générer une base et un modèle objet viable.

Il est très important de partir d'un schéma correcte.