Probleme schema.yml et fixture.yml

**butters** · 10/06/2010, 17h07

Bonjour,

Voila le début du problème. Je l'avais poster sur la partie doctrine, mais je viens vers vous (c.f. http://www.developpez.net/forums/d93...ulti-colonnes/)

J'aimerais savoir comment gérer des clé primaire composé.

J'ai faire un build-schema pour qu'il me génère mes models mais maintenant, j'aimerais pouvoir insérer des jeux d'essais dans mon fixture.yml

Je bloque lorsque je tente de vouloir faire la relation de type N-M ou sur au moins une table, il y a une clé primaire composé.

Je sais qu'il faut utiliser TABLE1: label de l'insertion mais j'ai droit à une jolie erreur 1452 (Erreur de foreign key).

Je m'y prend peut être mal donc je vien vers vous afin d'avoir un exemple si possible.

Merci d'avance,

Cordialement,

**Michel Rotta** · 10/06/2010, 17h29

Pour voir, mets ton shema.yml, on ne sait jamais.

D'expérience, les clefs composées, doctrine 1.2, il n'aime pas du tous, mais alors vraiment pas du tout. sauf dans les liaison n-n, on est peut-être sauvé !

**butters** · 10/06/2010, 17h37

J'ai mis le fichier en un peu simplifié Mais en gros, un article est identifié par une référence et un indice. Et un article peut être composé de plusieurs autres articles et donc, je me retrouve avec une relations N-M portant sur 2 clé primaire de chaque côté.

Je me suis dit que j'allais peut être mettre un id afin de n'avoir lus qu'une seul clé de part-et-d'autre.

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
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
 
ArticleType:
  connection: doctrine
  tableName: article_type
  columns:
    reference:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    indice_conf:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    id_ss_fam:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    nom:
      type: string(45)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
  relations:
    ArticleSousFamille:
      local: id_ss_fam
      foreign: id_ss_fam
      type: one
    ArticleComposition:
      local: reference
      foreign: reference
      type: many
    ArticleComposition_2:
      class: ArticleComposition
      local: indice_conf
      foreign: indice_conf
      type: many
    ArticleComposition_3:
      class: ArticleComposition
      local: reference
      foreign: reference1
      type: many
    ArticleComposition_4:
      class: ArticleComposition
      local: indice_conf
      foreign: indice_conf1
      type: many
    SitePossedeArticle:
      local: reference
      foreign: reference
      type: many
    SitePossedeArticle_2:
      class: SitePossedeArticle
      local: indice_conf
      foreign: indice_conf
      type: many
ArticleComposition:
  connection: doctrine
  tableName: article_composition
  columns:
    reference:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    indice_conf:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    reference1:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    indice_conf1:
      type: string(20)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: false
    quantite:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
  relations:
    ArticleType:
      local: reference
      foreign: reference
      type: one
    ArticleType_2:
      class: ArticleType
      local: indice_conf
      foreign: indice_conf
      type: one
    ArticleType_3:
      class: ArticleType
      local: reference1
      foreign: reference
      type: one
    ArticleType_4:
      class: ArticleType
      local: indice_conf1
      foreign: indice_conf
      type: one

Problème : Si je met qu'un seul id. Je me retrouve bloqué car j'ai aussi une relation ternaire et 1 des 3 récupère la clé primaire de chacun.

**Michel Rotta** · 10/06/2010, 18h14

On n'a pas, je pense que c'est volontaire, les table sous familles et reference.

Par contre, tu as fait un bon terrible hors des formes normales avec les multiples liaisons entre article_type et article_composition. Hors, dans ce que tu décris : "Et un article peut être composé de plusieurs autres articles ". Mais tu n'expliques pas la différence entre article type et article composition.

A priori de ce que je comprend de tes explications, mais qui ne colle pas avec le schéma :

un article a une sous famille, mais une sous famille peut avoir plusieurs article
un article a plusieurs référence, mais une référence n'a qu'un article
un article peut être lié à plusieurs articles, mais un article ne peut être lié qu'à un article ?

La relation au seins de tes articles n'est pas clair, est-ce qu'un article qui est lié à plusieurs articles peut aussi être référencé par plusieurs articles ? Ou avons nous un relation hiérarchiques avec plusieurs "root" ?

De plus, que représente physiquement l'article (ce serait plus simple si je pouvais visualiser, pour l'instant, je pense à des articles sur un blog, mais je pense être à côté de la plaque).

**butters** · 10/06/2010, 18h30

Bonjour,

C'est plus des articles genre produit fabriqué.

1/ En faite, un article est composé d'une référence et d'un indice mais deux articles peuvent avoir la même référence et un indice différent. Et vice versa.

2/ Un produit est composé d'un autre produit. Genre une voiturepossède 4 roues donc on aura une référence + indice pour la voitureet une référence + indice pour la roue et une quantité de 4 pour la relation de composition.

3/ Un produit fait partie d'une famille genre voiture. Et on aura donc par exemple différentes familles (break / citadine) .... (C'est un exemple).

Le schéma a été généré par doctrine lui-même, avec un build-schema.

J'espère avoir été clair.

Merci de ton aide et n'hésite pas s'il y a un point flou.

**Michel Rotta** · 10/06/2010, 19h11

Je pense que les tables références et indices, on s'en fout (un peu là). Par contre, on considère qu'un seul article peut avoir une combinaison référence + indice donnée, exacte ?

Pour garder ton exemple de voiture.

La voiture est un article, elle est composée de 4 roues. Dans ce cas, tu mets 4 fois l'objet roue ou une fois l'objet roue mais un argument nombre à 4 ?

La roue peut être utilisée sur plusieurs voitures différentes ?

La roue comprend une jante, un pneu et 4 boulons, la jante comprend un enjoliveur. Quant tu fais une recherche sur la voiture, tu dois avoir tous les éléments, quel que soit la profondeur ?

Doit-on considéré que l'article voiture (final) est au même niveau que l'article roue ?

**butters** · 11/06/2010, 08h42

Je pense que les tables références et indices, on s'en fout (un peu là). Par contre, on considère qu'un seul article peut avoir une combinaison référence + indice donnée, exacte ?

oui tout a fait, c'est grâce à ca qu'on peut trouver l'article. (Plus un identifiant fournisseur)

Pour garder ton exemple de voiture.

La voiture est un article, elle est composée de 4 roues. Dans ce cas, tu mets 4 fois l'objet roue ou une fois l'objet roue mais un argument nombre à 4 ?

Une fois l'objet roue et dans la table ArticleComposition, j'ai un argument quantité.

La roue peut être utilisée sur plusieurs voitures différentes ?

Oui, tout à fait.

La roue comprend une jante, un pneu et 4 boulons, la jante comprend un enjoliveur. Quant tu fais une recherche sur la voiture, tu dois avoir tous les éléments, quel que soit la profondeur ?

Oui, au final, j'ai un arbre qui donnera la composition de la racine.

Doit-on considéré que l'article voiture (final) est au même niveau que l'article roue ?

A priori, oui. Mais au final, une voiture ou une roue, c'est un produit donc les informations sur elle sont les mêmes

**Michel Rotta** · 11/06/2010, 09h48

Voilà le schéma que je te propose :

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
58
59
60
61
62
63
64
65
66
 
reference:
  columns:
    code: 
      type: string(20)
      unique: true
    label: string(50)
 
indice:
  columns:
    code: 
      type: string(20)
      unique: true
    label: string(50)
 
ssFam:
  columns:
    label: string(50)
 
article:
  tableName: article_type
  columns:
    reference_id: integer
    indice_id: integer
    ssFam_id: 
      type: integer
      notnull: true
    nom:
      type: string(45)
  indexes:
    refindice:
      fields: [ reference_id, indice_id ]
      type: unique
  relations:
    reference:
      local: reference_id
      foreign: id
      foreignAlias: articles
    indice:
      local: indice_id
      foreign: id
      foreignAlias: articles
    ssFam:
      local: ssFam_id
      foreign: id
      foreignAlias: articles
 
composition:
  tableName: article_composition
  columns:
    article_id: 
      type: integer
      primary: true
    articleElement_id:
      type: integer
      primary: true
    quantite: integer(4)
  relations:
    article:
      local: article_id
      foreign: id
      foreignAlias: composes
    element:
      local: article_id
      foreign: id
      foreignAlias: estComposes

Première remarque, ne laisse jamais doctrine faire le schéma pour toi, t'es sur de mourirrrr

Remarques sur le schéma :

J'ai rajouté des débuts de table pour les trois tables pour mieux comprendre le fonctionnement du schéma
Chaque table (sauf composition) a une clef auto-générée (nom: id, type: integer, primary). A noter que doctrine crée des big integer ( integer(8) )
La table article à donc trois liaisons 1-n vers sa référence, son indice et sa famille (pour le fournisseur, suit le modèle).
La table article à un indexe particulier, composé de la référence et de l'indice, indexe unique, qui permet d'assurer qu'il n'y aura par deux articles avec la même paire référence et indice, et ainsi simule la clef composé.
la table composition fait le lien entre l'article et ses éléments. C'est la seul table qui ait une clef primaire double.

Travailler avec le modèle :

Pour un article : $article (doctrine_record)
- le code de la la référence est trouvé par : $article->getReference()->getCode()
- la collection des articles qui le composes par : $article->getEstComposes() qui retourne un doctrine_collection
- la collection des articles qui sont composés par lui : $article->getComposes() qui retourne un doctrine_collection
pour un élément de la composition, l'article de base sera : $composition->getArticle()
pour un indice, la liste des articles sera : $indice->getArticles()
...

Bonne chance

**butters** · 11/06/2010, 10h52

Merci du temps que tu me consacre

.

Une interrogation. Avoir la liste des références et des indices ne me sert pas trop. Du coup, je pourrais simplifier le schema comme ceci non ?

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
article:
  tableName: article_type
  columns:
    reference: 
      type: string(20)
    indice: 
      type: string(20)
    ssFam_id: 
      type: integer
      notnull: true
    nom:
      type: string(45)
  indexes:
    refindice:
      fields: [ reference_id, indice_id ]
      type: unique
  relations:
    ssFam:
      local: ssFam_id
      foreign: id
      foreignAlias: articles

Et du coup, cela revient au même sans avoir la necessité de faire 2 requêtes jointure pour avoir les code correspondant.

Hier soir, en me penchant sur la table, c'est ce que j'était en train de me dire. Garder seulement un id transparent à l'utilisateur afin de gérer un int en clé primaire.

Donc finalement il vaut mieux ajouter des id générés automatiquement afin d'identifier une ligne ?

**Michel Rotta** · 11/06/2010, 11h23

Tu peux le faire pour les tables références et indice, disons que c'est contraire à ma philosophie personnel mais parfaitement viable.

Mais je le ferais un peu différemment.

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
 
reference:
  columns:
    code: 
      type: string(20)
      primary: true
    label: string(50)
 
article:
  tableName: article_type
  columns:
    reference_id: string(20)
    indice_id: string(20)
    ssFam_id: 
      type: integer
      notnull: true
    nom:
      type: string(45)
  indexes:
    refindice:
      fields: [ reference_id, indice_id ]
      type: unique
  relations:
    reference:
      local: reference_id
      foreign: id
      foreignAlias: articles
      ondelete: RESTRICT
      onupdate: CASCADE
    indice:
      local: indice_id
      foreign: id
      foreignAlias: articles
    ssFam:
      local: ssFam_id
      foreign: id
      foreignAlias: articles

On garde les même fonctionnalités. Note que le nom de la référence reste avec le suffixe _id, c'est important pour que les objets du modèles soient viables.

Pour un article ($article)

Tu récupère la référence par :
$article->getReferenceId()
Mais si tu veux le libellé de la référence :
$article->getReference()->getLibelle()
d'où l'importance d'avoir un nom de champ différent du nom du lien.

J'ai rajouté des traitement sur les delete (interdit) et les update (en cascade). Attention, a tester. Attention, il semblerait qu'en fonction des bases de données cela soit plus ou moins fiable, je manque expérience pour confirmer.

**butters** · 11/06/2010, 11h28

Merci beaucoup mais pourrais tu me montrer un exemple de fixture.yml pour la table compose ?

Vu qu'il y a 2 relation, je ne sais pas comment je doit les faire. Normalement, tu met le nom de la table genre

Code :

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

1
2
3
4
 
Compose:
   ArticleType: 1
   ArticleType: 2

Donc il ne va pas savoir lequel c'est. Donc peut être qu'on doit utiliser les foreignAlias ?

Code :

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

1
2
3
4
 
Compose:
   compose: 1
   estCompose: 2

**Michel Rotta** · 11/06/2010, 12h42

Un petit coup de fixture

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
 
reference:
  ref1:
    code: ABCD
  ref2:
    code: EFGH
 
indice:
  ind1:
    code: IJK
  ind2:
    code LMN
 
article:
  art1:
    reference: ref1
    indice: ind1
    nom: article 1
  art2:
    reference: ref2
    indice: ind1
    nom: article 11
  art3:
    reference: ref3
    indice: ind2
    nom: article 12
 
composition:
  compo1:
    article: art1
    element: art2
    quantite: 1
  compo2:
    article: art1
    element: art3
    quantite: 3

Pas testé, mais devrait marcher.

**butters** · 11/06/2010, 13h21

ok merci, ca marche impeccable !

Merci beaucoup pour ces informations et ta rapiditié

.

**butters** · 16/06/2010, 11h10

Nouvelle question concernant le schema yaml:

J'ai une relations ternaires un peu spécial :
1/ 1 article est publié dans plusieurs domaines (Nature - Science - Nouveautés ...).
2/ 1 domaines possède plusieurs article.
Ce qui va nous donner :

Code :

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

1
2
3
4
Article(id_art, champs ....)
Domaine(id_domaine, champs ...)
Publication(id_art, id_domaine)

Maintenant, on des personnes peuvent poster différents commentaire en fonction de l'article ET du domaine.
Donc a priori, si je me trompe pas, on a ceci :

Code :

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

1
2
3
4
5
Article(id_art, champs ....)
Domaine(id_domaine, champs ...)
Publication(id_art, id_domaine)
User(id_user, champs ...)
Commentaire(id_user, id_art, id_domaine)

Le problème est que du coup, le commentaire possède 2 champs étrangés

On pourrai mettre commentaire en (id_commentaire, id_user, id_art, id_domaine) mais je ne sais pas si cela règlera le problème du double champs étrangés sur une même table au niveau de doctrine.

J'ai ce problème car j'aimerais avoir un système comme ceci dans mon administration :
http://melikedev.com/2009/12/09/symf...relationships/ qui permettra l'ajout des domaines assez facilement

**butters** · 16/06/2010, 12h44

J'ai trouvé une solution qui marche MAIS je ne sais pas pourquoi cela marche :

database:

Code :

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

1
2
3
4
5
Article(id, ...)
Publication(id, article_id, domaine_id ...)
Domaine(id, ...)
Commentaire(id, publication_id

schema.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
 
Article:
  ...
  relations:
    Publication:
      class: Publication
      local: id
      foreign: article_id
      type: many
 
Publication:
  columns:
    article_id:
      type: integer
    domaine_id:
      type: integer
    ...
  relations:
    Article:
      class: Article
      local: article_id
      foreign: id
      type: one
    Domaine:
      class: Domaine
      local: domaine_id
      foreign: id
      type: one
 
Domaine:
    columns:
      ...
    relations:
      Publication:
        class: Publication
        local: id
        foreign: domaine_id
        type: many
      Article:
        class: Article
        refClass: Publication
        local: site_id
        foreign: article_id 
        foreignAlias: articles
 
Commentaire:
  columns:
    publication_id:
      type: integer
  relations:
     ....

Cela me donne pour l'article, un formulaire d'ajout avec une liste des domaines .
Et dans le domaine, une liste d'article.

Ce que je ne comprend pas, c'est comment il arrive a faire les 2 alors que j'ai spécifié que le lien dans une table ?

[Edition :] Problème résolu en enlevant le foreignAlias lors de la relation 'Domaine'

[Nouvelle question 1:] Comment faire en sorte que lorsque l'on édite une entrée dans la parti backend, on a le choix entre sauvegarder et donc faire un UPDATE ou faire un INSERT (j'aimerais avoir les 2 choix pour éviter, lorsque j'ai qu'un seul élément à changer, de tout me retaper. En faite, c'est une sorte d'insertion à partir d'un modèle existant.
[Nouvelle question 2:] En règle générale, avec doctrine, il vaut mieux de jamais mettre de clé primaire ? J'ai un

Code :

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

The "/articleComposition/:id/edit.:sf_format" route has some missing mandatory parameters (:Array).

sur une table possédant une clé primaire composé ( relation N-M ). Du coup, il vaut mieux mettre cela en champs avec un unique fiels [clé1, clé2] et un id unique ????

**Michel Rotta** · 17/06/2010, 01h28

[Nouvelle question 1:] Comment faire en sorte que lorsque l'on édite une entrée dans la parti backend, on a le choix entre sauvegarder et donc faire un UPDATE ou faire un INSERT (j'aimerais avoir les 2 choix pour éviter, lorsque j'ai qu'un seul élément à changer, de tout me retaper. En faite, c'est une sorte d'insertion à partir d'un modèle existant.

Tu peux créer des actions personnalisée, soit au niveau de la liste, soit au niveau de la totalité de la liste (les case à cocher). Il faut alors modifier les action.class.php et créer des exécute pour chaque action.

Je pense qu'en t'inspirant du code du module généré dans le cache, tu dois pouvoir faire un executeDuplique a partir d'un enregistrement existant et de le rediriger sur le template edit..;

[Nouvelle question 2:] En règle générale, avec doctrine, il vaut mieux de jamais mettre de clé primaire ? J'ai un .. sur une table possédant une clé primaire composé ( relation N-M ). Du coup, il vaut mieux mettre cela en champs avec un unique fiels [clé1, clé2] et un id unique ????

Tu as plusieurs possiblité, mais effectivement, il est plus simple d'avoir une clef unique avec un seul champ sur une table, c'est surtout vrai si tu as des relations qui repartent de cette table et qui aurait donc la clef composé plus un autre champ...

La solution est alors de simuler la clef unique en créant un index unique sur les trois champs et un champ id. C'est un peu bidouillage niveau MLD et formes normales, mais c'est efficace.

Si non, tu dois passer les trois champs de ta clef dans ta route.

Tu as une autre solution, c'est de créer un slug composé des trois éléments de la clef.

**butters** · 17/06/2010, 10h17

Envoyé par mimi68

Tu peux créer des actions personnalisée, soit au niveau de la liste, soit au niveau de la totalité de la liste (les case à cocher). Il faut alors modifier les action.class.php et créer des exécute pour chaque action.

Je pense qu'en t'inspirant du code du module généré dans le cache, tu dois pouvoir faire un executeDuplique a partir d'un enregistrement existant et de le rediriger sur le template edit..;

Ceci même dans la partie backend? Je vais tenter et je te vous tiens au courant.

Envoyé par mimi68

Tu as plusieurs possiblité, mais effectivement, il est plus simple d'avoir une clef unique avec un seul champ sur une table, c'est surtout vrai si tu as des relations qui repartent de cette table et qui aurait donc la clef composé plus un autre champ...

La solution est alors de simuler la clef unique en créant un index unique sur les trois champs et un champ id. C'est un peu bidouillage niveau MLD et formes normales, mais c'est efficace.

Si non, tu dois passer les trois champs de ta clef dans ta route.

Tu as une autre solution, c'est de créer un slug composé des trois éléments de la clef.

Laquel des deux solutions est la mieux entre passer les champs dans la route ou créer un slug composé ?

J'aimerais que dans un formulaire du backend, j'ai un sous formulaire pour la composition. Exemple:
Je décide d'avoir un Article 0,N <=Composé de N,N=> 0,NArticle
J'ai un formulaire pour ajouter un article (Exemple, une voiture) et j'aimerais un sous formulaire genre en forme de checkbox, afin d'avoir une liste d'éléments à cocher pour la composition.
J'ai ca dans mon champs relation :

Code :

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

1
2
3
4
5
    ArticleType:
      class: ArticleType
      refClass: ArticleComposition
      local: article_id
      foreign: article_compose_id

Ca me donne bien une liste que j'ai transformer en checkbox.

Mon problème est que maintenant, je veut rajouter la quantité afin de mettre par exemple: Ma voiture, je la met avec des roues en quantité 4 et je n'arrive pas a le faire. Un peu comme le principe d'un panier ou lorsque j'ai mon formulaire, je coche les choix des articles que je veut en indiquant la quantité.

**Michel Rotta** · 18/06/2010, 02h08

Ceci même dans la partie backend? Je vais tenter et je te vous tiens au courant.

Un peu tard ce soir, beaucoup de taf...

Il ne faut pas comprendre le module d'administration et le backup. Le backup est une application comme une autre, tu peux avoir n'importe quoi dans les backend. Et tu peux avoir un module d'administration dans le frontend.

Tu peux modifier le action.class.php d'un module d'administration et rajouter tes traitements.

Le module étends autoUser_xxxxx qui se trouve généré dans le cache. Tu peux donc mettre du traitement pour tes actions ou modifier le traitement standard d'une action.

Laquel des deux solutions est la mieux entre passer les champs dans la route ou créer un slug composé ?

Ca va pas de plaire, mais je dirais, celle qui conviens le mieux à ton application. A toi de voir.

Une remarque, le slug va prendre plus de place en base de donnée et plus de temps de traitement à chaque étape. Mais, dans certain cas, il pourra être mieux référencé par les moteur...

Pour la dernière question, il va falloir passer par des embedForm. Le problème c'est que tu ne pourras avoir toutes les options et cocher celles que tu veux. Plutôt une liste déroulante avec les options et le champs quantité à coté.

Après, il faudra peut-être un peu de javascript pour ne pas avoir à réaficher toute le page à chaque ajout d'option.

**butters** · 18/06/2010, 08h39

Un peu tard ce soir, beaucoup de taf...

Tu peux modifier le action.class.php d'un module d'administration et rajouter tes traitements.

Le module étends autoUser_xxxxx qui se trouve généré dans le cache. Tu peux donc mettre du traitement pour tes actions ou modifier le traitement standard d'une action.

Pas de problème. Merci de prendre du temps pour répondre à 2h du matin.

Je vais voir ce qui se trouve dans le cache et je tenterai de faire les modifications. Je verrai cela plus tard, je n'ai pas ma priorité.

Ca va pas de plaire, mais je dirais, celle qui conviens le mieux à ton application. A toi de voir.

Une remarque, le slug va prendre plus de place en base de donnée et plus de temps de traitement à chaque étape. Mais, dans certain cas, il pourra être mieux référencé par les moteur...

J'ai préféré mettre un id avec les deux clé primaires en index afin de facilité la chose.

Pour la dernière question, il va falloir passer par des embedForm. Le problème c'est que tu ne pourras avoir toutes les options et cocher celles que tu veux. Plutôt une liste déroulante avec les options et le champs quantité à coté.

Après, il faudra peut-être un peu de javascript pour ne pas avoir à réaficher toute le page à chaque ajout d'option.

Pour le moment, c'est ce que j'ai fait. Dommage qu'il n'existe pas cela en natif. Avec les relations direct dans le schema.yml, on arrive a afficher une liste avec possibilité de sélection multiple, les options afficher aurait pu faire partie de cela.

Je vais donc faire une boucle embedForm sur les relations existantes. Suivit d'un lien => Ajouter une relation. Ce lien sera obligatoirement en Ajax pour modifier le code html à la volé ? Il n'y a pas d'autre solution ?
Cela

**Michel Rotta** · 18/06/2010, 20h13

Je vais voir ce qui se trouve dans le cache et je tenterai de faire les modifications. Je verrai cela plus tard, je n'ai pas ma priorité.

Attention, on est bien d'accord, il ne faut rien modifier dans le cache... C'est régénéré régulièrement

Pour le moment, c'est ce que j'ai fait. Dommage qu'il n'existe pas cela en natif. Avec les relations direct dans le schema.yml, on arrive a afficher une liste avec possibilité de sélection multiple, les options afficher aurait pu faire partie de cela.

Je vais donc faire une boucle embedForm sur les relations existantes. Suivit d'un lien => Ajouter une relation. Ce lien sera obligatoirement en Ajax pour modifier le code html à la volé ? Il n'y a pas d'autre solution ?
Cela

En fait, symfony et doctrine considère que la table de liaison entre deux autres tables, dans le cadre d'une liaison n-n ne comporte que deux champs, aucun arguments complémentaires. Ces tables, il sait les gérer. Les autres, il faut le faire à la main.

Je pense que c'est la meilleur solution. Il faut juste penser a gérer la dégradation progressive des services, ton application doit être capable de fonctionner sans le javascript, moins vite, mais rester fonctionnel. De plus, elle doit rester lisible sans CSS, moins "sexy", mais utilisable.

Probleme schema.yml et fixture.yml

Symfony PHP

Discussions similaires

Partager

Partager