Formulaire de table n-n

**avalo** · 16/01/2011, 22h08

Bonjour à tous,

Je souhaite avoir votre aide sur mon problème actuel.

Je donne la création de la base de données peuplées. En passant, je valide la question que je posais sur la façon de peupler une BD avec attribut en relation n-n.

Création BD (/config/doctrine)

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
 
# -------------------------------------------------------------------
# Table des informations sur les clients
# --------------------------------------
# Relations :
#   Client(id) <1--N> Commande(client_id) <N--1> Article
# -------------------------------------------------------------------
Client:
  actAs:  { Timestampable: ~ }
  columns:
    id:
      type: integer(10)
      autoincrement: true
      primary: true
    nom:
      type: string(255)
      notnull : true
 
# --------------------------------------------------------------------
# Table des articles
# ------------------
# Relations :
#   Article(id) <1--N> Commande(article_id) <N--1> Client
#   Article(categorie_id) <N--1> Categorie(id)
# --------------------------------------------------------------------
Article:
  actAs:  { Timestampable: ~ }
  columns:
    id:
      type:           integer(10)
      autoincrement:  true
      primary:        true
    libelle:
      type:           string(25)
      notnull:        true
    categorie_id:
      type:           integer(10)
      notnull:        true
  relations:
    Clients:
      foreignAlias: Articles
      class:        Client
      refClass:     Commande
    Categorie:
      foreignAlias: Articles
 
# --------------------------------------------------------------------
# Table des catégories d'article
# ------------------------------
# Relations :
#   Categorie(id) <1--N> Article(article_id) 
# --------------------------------------------------------------------
Categorie:
  actAs:  { Timestampable: ~ }
  columns:
    id:
      type:           integer(10)
      primary:        true
      autoincrement:  true
    libelle:
      type:           string(100)
      notnull:        true
 
# ---------------------------------------------------------------------
# Table intermédiaire matérialisant les commandes passées par un client
# ---------------------------------------------------------------------
# Relations :
#   Client <1--N> Commande <N--1> Article
#   Commande(id) <N--1> Couleur(id)
# ---------------------------------------------------------------------
Commande:
  actAs:  { Timestampable: ~ }
  columns:
    client_id:
      type:     integer(10)
      primary:  true
    article_id:
      type:     integer(10)
      primary:  true
    nombre:
      type:     integer(4)  
    couleur_id:
      type:     integer(10)  
  relations:
    Client:
      foreignAlias: Commandes
    Article:
      foreignAlias: Commandes
    Couleur:
      foreignAlias: Commandes
 
# -----------------------------------------------------------------------
# Table de la liste des couleurs possibles pour un article d'une commande
# -----------------------------------------------------------------------
# Relations :
#   Couleur(id) <1--N> Commande(couleur_id) 
# -----------------------------------------------------------------------
Couleur:
  actAs:  { Timestampable: ~ }
  columns:
    id:
      type:           integer(10)
      primary:        true
      autoincrement:  true
    libelle:
      type:           string(20)
      notnull:        true

Création fixtures (/data/fixtures)

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
 
Client:
  cl_STE:
    nom:          Stéphane
  cl_ALA:
    nom:          Alain
  cl_BER:
    nom:          Bernard
 
Categorie:
  cat_MAI:
    libelle:  Maison
  cat_JAR:
    libelle:  Jardinage
  cat_INF:
    libelle:  Informatique
 
Couleur:
  co_BLA:
    libelle:  Blanc
  co_NOI:
    libelle:  Noir
  co_VER:
    libelle:  Vert
 
Article:
  art_CHA:
    libelle:    Chaise
    Categorie:  cat_MAI
  art_TAB:
    libelle:    Table
    Categorie:  cat_MAI
  art_ARM:
    libelle:    Armoire
    Categorie:  cat_MAI
  art_PEL:
    libelle:    Pelle
    Categorie:  cat_JAR
  art_RAT:
    libelle:    Rateau
    Categorie:  cat_JAR
  art_SAC:
    libelle:    Sarcloir
    Categorie:  cat_JAR
  art_MON:
    libelle:    Moniteur
    Categorie:  cat_INF
  art_POR:
    libelle:    Portable
    Categorie:  cat_INF
  art_ALI:
    libelle:    Alimentation
    Categorie:  cat_INF
 
Commande:
  co_STE01:
    Client:   cl_STE
    Article:  art_CHA
    nombre:   4
    Couleur:  co_VER
  co_STE02:
    Client:   cl_STE
    Article:  art_TAB
    nombre:   1
    Couleur:  co_NOI
  co_STE03:
    Client:   cl_STE
    Article:  art_RAT
    nombre:   1
    Couleur:  co_NOI
  co_ALA01:
    Client:   cl_ALA
    Article:  art_RAT
    nombre:   1
    Couleur:  co_NOI
  co_ALA02:
    Client:   cl_ALA
    Article:  art_PEL
    nombre:   3
    Couleur:  co_NOI
  co_BER01:
    Client:   cl_BER
    Article:  art_MON
    nombre:   1
    Couleur:  co_BLA
  co_BER02:
    Client:   cl_BER
    Article:  art_ALI
    nombre:   2
    Couleur:  co_NOI

Et vlan, je génère le bidule...
php symfony doctrine:build --all --no-confirmation --and-load

L'inévitable création du module qui va bien :
php symfony doctrine:generate-module --with-show --non-verbose-templates frontend client Client

Et enfin la question
Je n'arrive pas, et j'ai pourtant essayé avec l'aide de la doc : 06-Advanced-Forms, à faire un formulaire qui me permette pour un client donné de créer une commande telle que celle-ci :

Le formulaire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CLIENT : [nom]
COMMANDE :
1 | [categorie] | [article] | [couleur] | [nombre] | [x]
2 | [categorie] | [article] | [couleur] | [nombre] | [x]
3 | [categorie] | [article] | [couleur] | [nombre] | [x]
 
[___________]^ | [___________]^ | [________]^ | [__]
 Catégorie        Article          Couleur       Nb
 
[+]
 
[save]

Comportements :
1/ CLIENT et COMMANDE sont renseignés avec les données actuelles
2/ le champ "Catégorie" présente la liste des catégories, on en choisit une et cela met à jour la liste des articles à côté, on choisit un article, la couleur et le nombre
3/ lorsque je clique sur le [+], j'ajoute une ligne avec laquelle je peux saisir une nouvelle ligne de commande
4/ lorsque je clique sur le [x], je supprime la ligne
5/ je clique sur le bouton [save] et tout est envoyé dans la BD

J'ai bien compris que tout se joue au niveau de lib/form avec les Form.class.php mais je n'ai pas réussi à les enchaîner, j'ai des résultats partiels mais rien qui ressemble ...
Mes essais ressemblent aux clones de Ripley ... y-a toujours un truc qui est difforme

Si une bonne âme peut m'aider

, qu'elle ne se soucis pas de la présentation ... dans un premier temps.

**Michel Rotta** · 17/01/2011, 10h22

Donc, la création des tables est ok et le peuplement aussi.

Quelques remarques qui pourraient être constructives sur ton schéma:

Par convention dans symfony, et sauf si tu as des besoins très particulier, les clefs sont de type integer (sans longueur). De plus, pour simplifier ton schéma et sa lecture, si aucune clef primaire n'est définie, doctrine rajoute une clef primaire Id auto-incrémentée.
J'ai du mal à comprendre l'intérêt de définir un lien de type n-n entre article et client, même s'il et syntaxiquement correcte.
Ta commande ne peut réellement concerner qu'un article ???
Tu aurais intérêt à reprendre dans la table de liaison entre article et la commande (ici, bizarrement, commande) l'ensemble des informations de l'article. Cela peut paraître redondant et non conforme aux formes normales, mais, en fait, ce sont les références au moment de la commande, un article est susceptible d'évoluer dans le temps (le prix notamment) il se révèle alors impossible de réimprimer, à l'identique, de vielle commande.
La même réflexion vaut pour les données du client pour chaque commande.

Pour ton formulaire, je t'invite à consulter la page "Les plugins les plus intéressants pour symfony 1.4.x et doctrine" et notamment le plugin : ahDoctrineEasyEmbeddedRelationsPlugin qui devrait te simplifier la vie très largement.

**avalo** · 17/01/2011, 21h43

Merci Michel pour tes remarques parfaitement constructives

Voilà maintenant un client passe une ou plusieurs commandes qui comportent un ou plusieurs articles.
Je pense que maintenant les relations sont plus conformes.

Je comprends tes remarques concernant la structure d'un projet réel de commande mais mon propos est de définir un modèle de relations pour me permettre de travailler sur les formulaires. Mais tu as raison, autant que cela ne soit pas complétement absurde.

J'ai refait le schema.yml en tenant compte de tes remarques.

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
 
# -------------------------------------------------------------------
# Table des informations sur les clients
# --------------------------------------
# Relations :
#   Client(id) <--N> Commande(client_id)
# -------------------------------------------------------------------
Client:
  actAs:  { Timestampable: ~ }
  columns:
    nom:
      type: string(255)
      notnull : true
 
# -------------------------------------------------------------------
# Table des commandes passées par un client
# -----------------------------------------
# Relations :
#   Commande(id) <1--N> CommandeArticle(commande_id) <N--1> Article
#   Commande(client_id) <N--1> Client(id)
# -------------------------------------------------------------------
Commande:
  actAs:  { Timestampable: ~ }
  columns:
    client_id:
      type: integer
      notnull : true
  relations:
    Client:
      foreignType:  many
      foreignAlias: Commandes
 
# --------------------------------------------------------------------
# Table des articles
# ------------------
# Relations :
#   Article(id) <1--N> CommandeArticle(article_id) <N--1> Commande
#   Article(categorie_id) <N--1> Categorie(id)
# --------------------------------------------------------------------
Article:
  actAs:  { Timestampable: ~ }
  columns:
    libelle:
      type:           string(25)
      notnull:        true
    categorie_id:
      type:           integer
      notnull:        true
  relations:
    Commandes:
      foreignAlias: Articles
      class:        Commandes
      refClass:     CommandeArticle
    Categorie:
      foreignAlias: Articles
 
# --------------------------------------------------------------------
# Table des catégories d'article
# ------------------------------
# Relations :
#   Categorie(id) <1--N> Article(article_id) 
# --------------------------------------------------------------------
Categorie:
  actAs:  { Timestampable: ~ }
  columns:
    libelle:
      type:           string(100)
      notnull:        true
 
# ---------------------------------------------------------------------
# Table intermédiaire matérialisant les commandes passées par un client
# ---------------------------------------------------------------------
# Relations :
#   Commande <1--N> CommandeArticle <N--1> Article
#   CommandeArticle(couleur_id) <N--1> Couleur(id)
# ---------------------------------------------------------------------
CommandeArticle:
  actAs:  { Timestampable: ~ }
  columns:
    commande_id:
      type:     integer
      primary:  true
    article_id:
      type:     integer
      primary:  true
    nombre:
      type:     integer(4)  
    couleur_id:
      type:     integer
  relations:
    Commande:
      foreignAlias: CommandesArticles
    Article:
      foreignAlias: CommandesArticles
    Couleur:
      foreignAlias: CommandesArticles
 
# -----------------------------------------------------------------------
# Table de la liste des couleurs possibles pour un article d'une commande
# -----------------------------------------------------------------------
# Relations :
#   Couleur(id) <1--N> Commande(couleur_id) 
# -----------------------------------------------------------------------
Couleur:
  actAs:  { Timestampable: ~ }
  columns:
    libelle:
      type:           string(20)
      notnull:        true

Et les fixtures :

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
120
121
122
123
124
125
126
127
 
Client:
  cl_STE:
    nom:          Stéphane
  cl_ALA:
    nom:          Alain
  cl_BER:
    nom:          Bernard
 
Commande:
  co_STE01:
    Client:   cl_STE
  co_STE02:
    Client:   cl_STE
  co_ALA01:
    Client:   cl_ALA
  co_ALA02:
    Client:   cl_ALA
  co_BER01:
    Client:   cl_BER
 
CommandeArticle:
  ca_STE0101:
    Commande: co_STE01
    Article:  art_CHA
    nombre:   4
    Couleur:  co_VER
  ca_STE0102:
    Commande: co_STE01
    Article:  art_TAB
    nombre:   1
    Couleur:  co_NOI
  ca_STE0103:
    Commande: co_STE01
    Article:  art_RAT
    nombre:   1
    Couleur:  co_NOI
 
  ca_STE0201:
    Commande: co_STE02
    Article:  art_CHA
    nombre:   2
    Couleur:  co_VER
  ca_STE0202:
    Commande: co_STE02
    Article:  art_TAB
    nombre:   1
    Couleur:  co_BLA
 
  co_ALA0101:
    Commande: co_ALA01
    Article:  art_RAT
    nombre:   1
    Couleur:  co_NOI
  co_ALA0102:
    Commande: co_ALA01
    Article:  art_PEL
    nombre:   3
    Couleur:  co_NOI
 
  co_ALA0201:
    Commande: co_ALA02
    Article:  art_SAR
    nombre:   1
    Couleur:  co_NOI
  co_ALA0202:
    Commande: co_ALA02
    Article:  art_PEL
    nombre:   3
    Couleur:  co_NOI
 
  co_BER0101:
    Commande: co_BER01
    Article:  art_MON
    nombre:   1
    Couleur:  co_BLA
 
  co_BER0102:
    Commande: co_BER01
    Article:  art_ALI
    nombre:   2
    Couleur:  co_NOI
 
Article:
  art_CHA:
    libelle:    Chaise
    Categorie:  cat_MAI
  art_TAB:
    libelle:    Table
    Categorie:  cat_MAI
  art_ARM:
    libelle:    Armoire
    Categorie:  cat_MAI
  art_PEL:
    libelle:    Pelle
    Categorie:  cat_JAR
  art_RAT:
    libelle:    Rateau
    Categorie:  cat_JAR
  art_SAR:
    libelle:    Sarcloir
    Categorie:  cat_JAR
  art_MON:
    libelle:    Moniteur
    Categorie:  cat_INF
  art_POR:
    libelle:    Portable
    Categorie:  cat_INF
  art_ALI:
    libelle:    Alimentation
    Categorie:  cat_INF
 
Categorie:
  cat_MAI:
    libelle:  Maison
  cat_JAR:
    libelle:  Jardinage
  cat_INF:
    libelle:  Informatique
 
Couleur:
  co_BLA:
    libelle:  Blanc
  co_NOI:
    libelle:  Noir
  co_VER:
    libelle:  Vert

J'avais bien noté, dans tes réponses sur d'autres posts, l'existence du plugin ahDoctrineEasyEmbeddedRelations mais je n'ai pas réussi à le mettre en oeuvre dans mon exemple.

Ce dont j'aurais besoin, c'est d'un petit coup de pouce sur l'écriture de la fonction configure() dans les différentes form. Autant cela ne me pose pas de problème pour un form mais dans l'enchaînement je m'y perds

Merci d'avance pour votre temps !

**Michel Rotta** · 18/01/2011, 11h43

Je propose de commencer par optimiser le schéma.

Une relation est, par défaut, en 1-n. Donc le "type" ou "foreignType" n'a pas d'intérêt dans ce cas là et on gagne un peu en lisibilité et en taille du shema.yml. Quant, comme dans ton schéma, les noms des champs sont conforme à la norme, et que le nom de la relation est le nom de la classe, seul le "foreignAlias" est nécessaire. D’ailleurs, sur la fin, c'est bien ce que tu fais. On peut aller plus loin et dire à doctrine de trouver seul les relations, mais ceci, bien que sur un petit schéma cela marche bien, me laisse un peu angoissé
Normalement, tu devrais reprendre, dans la table commande, les informations du client (je suppose que le schéma ici est allégé). L'objectif est de pouvoir ressortir une commande à l'identique longtemps après, même si le client à rectifié son nom où déménagé. De la même manière, il faut reprendre dans CommandeArticle le détail de l'article, Accessoirement, cela permet de supprimer un article sans risquer de perdre les commandes en historique.
Je ne suis pas convaincu de l'utilité de la définition d'une relation n-n entre commandes et articles.
Un poil plus hard. Je suppose que le client va devoir s'identifier avant de passer une commande. De la même manière, je suppose que le personnel de la boutique va devoir s'identifier avant de servir les commandes. Il faut donc prévoir une série de table pour savoir qui est qui, quel sont les droits dans l'application et qui a quel droits. Il existe un plugin qui gère cela, sfDoctrineGuardPlugin, voir dans le dossier plugin la liste des plugins. De même, je suppose que le client doit pouvoir créer seul son compte, il y a un plugin qui se greffe sur sfGuard et permet ce type de manipulation. Dans ce cas là, je pense qu'il serait bien que la table client et la table sf_guard_user soient fusionnées, il convient ici d'utiliser la notion d'héritage décrite dans les read-me des plugins et largement commentée dans plusieurs sujets ici.

Pour la saisie :

La table client ne doit pas poser de problème. Deux modules, un pour l'administration en backend (avec le générateur d'admin) et un pour le client qui ne pourra modifier que son profil.
La table article est aussi simple. Je vois que tu n'as pas de notion de panier, ce qui facilite les choses. Un formulaire en backend (avec le générateur d'admin) devrait suffire.
les autres tables de paramètres n'existeront probablement qu'en backend
Donc a priori, le seul écran un peu compliqué est celui des factures. Commence par faire un écran qui marche pour la modification de factures existante. On parlera ensuite de la création.

**avalo** · 22/01/2011, 23h17

@Michel : Merci pour tes remarques ... pertinentes.

Comme je le disais dans mon post précédent, mon but n'est pas tant de valider avec toi, la structure d'un projet dans un fonctionnement réel que de me donner un exemple qui me permette de construire des formulaires et de tester les fonctionnalités offertes par les plugins ad hoc.

Je note et j'apprécie ton professionnalisme et je saurais y faire appel plus tard avec mon projet réel. Je suis en pleine réflexion sur le modèle.

Je suis d'accord avec toi sur les lacunes que portent mon exemple s'il devait être exploité dans un environnement de production.

Donc j'utilise le plugin qui a un nom à coucher dehors avec un billet de logement : ahDoctrineEasyEmbeddedRelations

Je n'ai pas de problème pour faire afficher la liste des clients :

Code :

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

1
2
3
4
5
6
Liste des clients

Id 	Nom
1 	Stéphane
2 	Alain
3 	Bernard

Lorsque l'on clique sur le nom, on obtient les commandes qu'un client donné a passées :

Code :

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

1
2
3
4
5
6
7
8
Liste des commandes

Id:     1
Nom:  Stéphane
Commande: 1   Voir   Editer
Commande: 2   Voir   Editer

List   Nouvelle commande

Je n'ai pas mis le code utiliser pour protéger les arbres

mais je peux le faire si besoin.

[Voir] ne me pose pas de problème

Par contre [Editer] et [Nouvelle commande] reste un mystère pour moi.
Je suppose que [Nouvelle commande] appelle executeNewOrder dans clientActions puis passe la main au template newOrderSuccess et à ce moment il faut donc créer un formulaire CommandeForm avec un objet CommandeForm() ... et la je ne sais plus

je suis perdu ...

**Michel Rotta** · 23/01/2011, 10h18

Désolé, je n'avais pas compris dans tes posts précédent que c'était un outil de travail du développeur et pas une future application. Ce qui ne changerais pas beaucoup contenu des réponses, sauf qu'elles seraient moins intrusives

Pour le plugin, dans mes souvenirs, tu as la possibilité de définir dans le tableau d'argument d'initialisation les modules, action pour la création d'un nouveau enregistrement. Je crois même qu'on peut y définir un paramètre (comme le numéro de la commande).

Si non, tu as la possibilité de désactiver la création dans le plugin et de créer, dans ton display, en dessous de la liste un form pour la saisie d'un nouvel enregistrement.

Formulaire de table n-n

PHP

Vue hybride

Discussions similaires

Partager

Partager