problème action Edit_table association

Version imprimable

Bonjour,

j'utilise symfony pour créer une application de gestion d'articles.
je dispose de 3 entités : "article", "fournisseur" et "stock" avec une relation "articleLivré" reliant ces 3 entités avec une cardinalité (1,n). Alors dans mon schéma de BD j'obtiens en plus des tables des 3 entités, une 4ème table "article livré" qui contient les 3 clés étrangères (Les Id des entités) + date livraison + quantité stockée.

J'ai besoin en fait que l'utilisateur puisse rentrer dans le frontend la date et la quantitée livrée correspondant au bon produit. J'ai créé un module "livraison" associée à la table "articleLivré" sauf que le problème que j'ai, c'est que l'action Edit ne permet pas de choisir un Id spécifique de produit, un Id de fournisseur ou un Id de stock (Alors que sur phpmyAdmin il me propose de choisir un Id parmi tous les Id de produits présents quand j'insère un enregistrement dans la table "articleLivré"...).

Je ne sais pas vraiment comment faire?? :roll:

Est-ce qu'il faut modifier l'action executeEdit? et par la même occasion, comme les Id ne sont pas parlants, est-ce qu'on peut afficher en plus les noms d'article et de fournisseur dans 'L'Edit" qu'on récupère à partir des tables "article" et "fournisseur"?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 public function executeEdit(sfWebRequest $request) { $this->forward404Unless($article_livre_fournisseur_stock = Doctrine_Core::getTable('articleLivre')->find(array($request->getParameter ('article_id'), $request->getParameter('fournisseur_id'), $request->getParameter('stock_id'))), sprintf('Object article_livre_fournisseur_stock does not exist (%s).', $request->getParameter('article_id'), $request->getParameter('fournisseur_id'), $request->getParameter('stock_id'))); $this->form = new articleLivreForm($article_livre_fournisseur_stock); }
Merci pour votre aide!!!

15/03/2011, 11h31
Michel Rotta

Tu veux faire un formulaire de recherche évolué ?

Ta recherches doit te retourner plusieurs ligne ou une seul ligne ?
15/03/2011, 12h09
flora806

Citation:

Envoyé par Michel Rotta

Tu veux faire un formulaire de recherche évolué ?

Ta recherches doit te retourner plusieurs ligne ou une seul ligne ?

En fait, c'est pas vraiment une recherche évoluée, mais juste au niveau du formulaire d'édition ou de Nouvel enregistrement de la table "articleLivré", avoir la possibilité de choisir entre les différents Id (clés étrangères) possibles et avoir en plus le nom de l'article, du fournisseur..associé à chaque Id.
15/03/2011, 12h19
Michel Rotta

Normalement, si ton shema.yml est bon, tu devrais avoir automatiquement des widget sélection sous forme de liste qui sont générés.

Si ce n'est pas le cas, met ton shema.yml, pour voir.

Citation:

Envoyé par Michel Rotta

Normalement, si ton shema.yml est bon, tu devrais avoir automatiquement des widget sélection sous forme de liste qui sont générés.

Si ce n'est pas le cas, met ton shema.yml, pour voir.

Voici mon 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
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
 
Fournisseur:
  connection: doctrine
  tableName: fournisseur
  actAs: { Timestampable: ~ }
  columns:
    nom_fournisseur:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
	.....
    user_creation:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    user_maj:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
 
Stock:
  connection: doctrine
  tableName: stock
  actAs: { Timestampable: ~ }
  columns:
    numero:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    user_creation:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    user_maj:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
 
Article:
  connection: doctrine
  tableName: article
  actAs: { Timestampable: ~ }
  columns:
    id:  { type: integer, notnull: true, primary: true }
    nom_article:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    n_inventaire:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    .......
    creation_user:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    update_user:
      type: string()
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
 
ArticleLivre:
  connection: doctrine
  tableName: articlelivre
  actAs: { Timestampable: ~ }
  columns:
    article_id:  { type: integer, notnull: true, primary: true }  
    fournisseur_id:  { type: integer, notnull: true, primary: true }  
    stock_id:  { type: integer, notnull: true, primary: true }   
    date_livraison:
      type: date(25)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    quantite:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
  relations:	  
    Article: { onDelete: RESTRICT, local: article_id, foreign: id}
    Fournisseur:   { onDelete: RESTRICT, local: fournisseur_id, foreign: id}
    Stock:   { onDelete: RESTRICT, local: stock_id, foreign: id}

15/03/2011, 14h19
Michel Rotta

Tu peux déjà virer tous ce qui est truc: false qui est la valeur par défaut, cela va alléger le schéma.

J'ai des doutes sur une clef primaire à trois champs. Doctrine 1.2 a beaucoup de mal à gérer les clefs à deux champs, alors 3... A ta place je ferais trois clefs indépendantes et une clef primaire Id de son côté. Ceci n’empêche pas de créer un index regroupent les trois clef et, éventuellement, unique. De plus ta clef à trois champs me semble assez limitative dans la mesure où un article ne dans une position de stock fourni par un fournisseur ne peut avoir qu'une liaison qui me semble être proche d'une vente. Une vente pour un article lié et on le jette ?

Puis juste un point de rhétorique (vu que tu vas, je pense, modifier le schéma là), pourquoi mettre un notnull sur un élément constituant la clef primaire ?
15/03/2011, 14h47
flora806

Citation:

Envoyé par Michel Rotta

Tu peux déjà virer tous ce qui est truc: false qui est la valeur par défaut, cela va alléger le schéma.

J'ai des doutes sur une clef primaire à trois champs. Doctrine 1.2 a beaucoup de mal à gérer les clefs à deux champs, alors 3... A ta place je ferais trois clefs indépendantes et une clef primaire Id de son côté. Ceci n’empêche pas de créer un index regroupent les trois clef et, éventuellement, unique. De plus ta clef à trois champs me semble assez limitative dans la mesure où un article ne dans une position de stock fourni par un fournisseur ne peut avoir qu'une liaison qui me semble être proche d'une vente. Une vente pour un article lié et on le jette ?

Puis juste un point de rhétorique (vu que tu vas, je pense, modifier le schéma là), pourquoi mettre un notnull sur un élément constituant la clef primaire ?

J'ai pas très bien compris les clefs indépendantes et une clé primaire du côté de la table de jointure...
Si c'est trop compliqué à faire, je vais concevoir l'appli autrement, je pourrais ne garder que la jointure entre table "article" et "fournisseur" et à ce moment là j'aurai 2 clés étangères, est-ce que symfony peut gérer ça?

Si c'est ça, j'aurai quand même une table jointure "articlelivre" avec les 2 attributs en plus "date livraison" et "quantité".
Alors mon autre question c'était, si je crée un module frontend "livraison" comment je pourrais récupérer le nom d'un article et le nom d'un fournisseur à partir des actions de ce module?

Merci pour vos réponses ;)
15/03/2011, 15h08
Michel Rotta

Il n'y a pas de rapport entre une clef primaire et une liaison entre deux tables. Tu peux avoir 40 liaisons d'une table vers 40 table et avoir une clef primaire constituée d'un champ.

Commence par mettre une clef primaire unique (id) (pas de déclaration de primary, doctrine s'en chargera) et fait tes trois liaisons tranquillement, ton schéma et ton application devraient s'en porter mieux.

Citation:

Envoyé par Michel Rotta

Il n'y a pas de rapport entre une clef primaire et une liaison entre deux tables. Tu peux avoir 40 liaisons d'une table vers 40 table et avoir une clef primaire constituée d'un champ.

Commence par mettre une clef primaire unique (id) (pas de déclaration de primary, doctrine s'en chargera) et fait tes trois liaisons tranquillement, ton schéma et ton application devraient s'en porter mieux.

Je conserve quand même les Id (clés étrangères) dans la table de liaison en supprimant "primary=true"? y a pas à rajouter les foreignAlias (dont je comprends pas bcp l'utilité)?

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
 
Fournisseur:
  connection: doctrine
  tableName: fournisseur
  actAs: { Timestampable: ~ }
  columns:
    nom_fournisseur:
      type: string()
	.....
 
Stock:
  connection: doctrine
  tableName: stock
  actAs: { Timestampable: ~ }
  columns:
    numero:
      type: string()
 
Article:
  connection: doctrine
  tableName: article
  actAs: { Timestampable: ~ }
  columns:
    id:  { type: integer, notnull: true, primary: true }
    nom_article:
      type: string()
    n_inventaire:
      type: string()
     .......
    creation_user:
      type: string()
    update_user:
      type: string()
 
ArticleLivre:
  connection: doctrine
  tableName: articlelivre
  actAs: { Timestampable: ~ }
  columns:
    id:  { type: integer, notnull: true, primary: true }
    article_id:  { type: integer, notnull: true }  
    fournisseur_id:  { type: integer, notnull: true }  
    stock_id:  { type: integer, notnull: true}   
    date_livraison:
      type: date(25)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
    quantite:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
  relations:	  
    Article: { onDelete: RESTRICT, local: article_id, foreign: id}
    Fournisseur:   { onDelete: RESTRICT, local: fournisseur_id, foreign: id}
    Stock:   { onDelete: RESTRICT, local: stock_id, foreign: id}

Le shema à ma façon
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 Fournisseur: connection: doctrine tableName: fournisseur actAs: { Timestampable: ~ } columns: nom_fournisseur: type: string(255) ..... Stock: connection: doctrine tableName: stock actAs: { Timestampable: ~ } columns: numero: type: string(255) Article: connection: doctrine tableName: article actAs: { Timestampable: ~ } columns: nom_article: string(255) n_inventaire: string(255) ....... creation_user_id: integer update_user_id: integer relations: // faire les relations avec la table user. ArticleLivre: connection: doctrine tableName: articlelivre actAs: { Timestampable: ~ } columns: article_id: type: integer notnull: true fournisseur_id: type: integer notnull: true stock_id: type: integer notnull: true date_livraison: date quantite: integer(4) relations: Article: onDelete: RESTRICT foreignAlias: ArticleLivres Fournisseur: onDelete: RESTRICT foreignAlias: ArticleLivres Stock: onDelete: RESTRICT foreignAlias; ArticleLivres
Pas de valeur par défaut déclarée au shema.yml
dans la relation, local a par défaut le nom de la classe en relation plus "_id" donc on laisse par défaut.
dans la relation, foreign a par défaut "id"...
dans la relation, foreignAlias a par défaut la classe de définition de la relation (ici ArticleLivre). Je remplace par ArticleLivres (avec "s") pour indiquer qu'il y a plusieurs ArticleLivre pour un article. Le foreignAlias est le nom de la relation vue depuis la classe de l'autre côté de la relation.
Mettre une longueur a string, si non il fait un champ trop grand et mange de la place inutilement.
Si pas de clef primaire définie il en crée une par défaut (Id, integer).
Pour la lisibilité, il faut éviter de mélanger les syntaxe de base et par {} dans le shema.

Pose des questions sur ce qui n'est pas claire... :ccool:

Merci Michel Rotta pour toutes ces explications, c'est très sympa!!!
là j'ai corrigé mon schéma et mon module livraison marche presque :?

En fait les actions "Edit" ou "list" marchent bien. La seule action qui fonctionne pas comme je veux c'est "New", càd quand je veux rajouter une nouvelle ligne livraison. En fait il ne m'affiche pas du tout les Ids d'article ou de fournisseur ou de labo. il affiche uniquement le formulaire avec date livraison et quantité.
Alors quand je fais "save" j'ai cette erreur:

SQLSTATE[HY000]: General error: 1452 Cannot add or update a child row: a foreign key constraint fails

c'est normal parce que j'avais aucun id de produit, ni de fournisseur...mais je ne sais pas comment les rendre visibles au niveau du formulaire pour permettre à l'utilisateur de les informer.

Voici un aperçu du fichier "_form" du module livraison
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 <?php use_stylesheets_for_form($form) ?> <?php use_javascripts_for_form($form) ?> <form action="<?php echo url_for('livraison/'.($form->getObject()->isNew() ? 'create' : 'update').(!$form->getObject()->isNew() ? '?article_id='.$form->getObject()->getArticleId().'&fournisseur_id='.$form->getObject()->getFournisseurId().'&stock_id='.$form->getObject()->getStockId() : '')) ?>" method="post" <?php $form->isMultipart() and print 'enctype="multipart/form-data" ' ?>> <?php if (!$form->getObject()->isNew()): ?> <input type="hidden" name="sf_method" value="put" /> <?php endif; ?> <table> <tfoot> <tr> <td colspan="2">  <a href="<?php echo url_for('livraison/index') ?>">Back to list</a> <?php if (!$form->getObject()->isNew()): ?>  <?php echo link_to('Delete', 'livraison/delete?article_id='.$form->getObject()->getArticleId().'&fournisseur_id='.$form->getObject()->getFournisseurId().'&stock_id='.$form->getObject()->getStockId(), array('method' => 'delete', 'confirm' => 'Are you sure?')) ?> <?php endif; ?> <input type="submit" value="Save" /> </td> </tr> </tfoot> <tbody> <?php echo $form ?> </tbody> </table> </form>

15/03/2011, 18h02
flora806
Finalement, j'ai résolu le problème de cette erreur SQL lié à la clé étrangère.
j'ai fait ça en modifiant les Widgets et j'ai réussi à avoir dans le formulaire d'ajout d'une nouvelle livraison, la liste proposant les Id des articles, Id fournisseurs...
par contre j'arrive pas encore à afficher plutôt la liste des noms des articles et des noms de fournisseurs. :roll:

je me demande s'il faut le faire au niveau des Widgets aussi ou ailleurs :roll:
Code:

1 2 3 4 $this->setWidgets(array( 'article_id' => new sfWidgetFormDoctrineChoice(array('model' => $this->getRelatedModelName('Article'), 'add_empty' => false)), ..............
15/03/2011, 18h04
Michel Rotta

La seul chose a tirer de ce template c'est que tu affiches simplement le formulaire :

Code:

<?php echo $form ?>

Ce qui permet au moins de déjà retirer une bonne centaine de causes possibles... :ccool:

Mais, tu dis : "En fait il ne m'affiche pas du tout les Ids d'article ou de fournisseur ou de labo". Ce qui me laisse entendre que tu n'as pas les mêmes champs pour l'édition que pour la création.

Vu que ceci n'est pas modifié au niveau du template c'est que tu dois avoir des trucs particuliers dans ton contrôleur ou un double formulaire. Qu'en est-il ?
15/03/2011, 18h16
flora806
Citation:

Envoyé par Michel Rotta

La seul chose a tirer de ce template c'est que tu affiches simplement le formulaire :

Code:

<?php echo $form ?>

Ce qui permet au moins de déjà retirer une bonne centaine de causes possibles... :ccool:

Mais, tu dis : "En fait il ne m'affiche pas du tout les Ids d'article ou de fournisseur ou de labo". Ce qui me laisse entendre que tu n'as pas les mêmes champs pour l'édition que pour la création.

Vu que ceci n'est pas modifié au niveau du template c'est que tu dois avoir des trucs particuliers dans ton contrôleur ou un double formulaire. Qu'en est-il ?

Je ne sais pas si tu as lu ma dernière réponse...
Donc le problème était dû à ça (dans la classe "BaseArticleLivreForm")
Code:

1 2 3 4 5 6 public function setup() { $this->setWidgets(array( 'article_id' => new sfWidgetFormInputHidden(), ..........}
donc le champ Id était caché dans le formulaire.

maintenant comment faire pour afficher les noms des articles au lieu des Id?

Merci d'avance!!!
16/03/2011, 09h55
Michel Rotta

Je traite plus de 10 questions différentes par jour, je n'ai jamais eu la prétention de pouvoir connaître tous les problèmes dans le détail.

Mais, sans citer le module, que j'ai eu du mal a retrouver dans la discutions, je ne dis pas le contraire.

Chose importante, il ne faut jamais modifier un form auto généré, c'est a dire ceux que l'on retrouve sous la forme lib/form/doctrine/base/BaseXxxxForm.class.php. En effet, ceux-ci sont successible d'être régénérer à n'importe quel moment et donc d'engendrer la perte de toutes les modifications.

Par contre il n'est pas logique que sur BaseArticleLivreForm le widget généré pour un champ de liaison soit de type hidden. Il devrait être de type select (soit une liste déroulante par défaut).

Il convient donc de régénérer les objets base avec une commande "build --all". Attention, celle-ci supprime la base de données avant de la recréer...
16/03/2011, 11h37
flora806

Citation:

Envoyé par Michel Rotta

Je traite plus de 10 questions différentes par jour, je n'ai jamais eu la prétention de pouvoir connaître tous les problèmes dans le détail.

Mais, sans citer le module, que j'ai eu du mal a retrouver dans la discutions, je ne dis pas le contraire.

Chose importante, il ne faut jamais modifier un form auto généré, c'est a dire ceux que l'on retrouve sous la forme lib/form/doctrine/base/BaseXxxxForm.class.php. En effet, ceux-ci sont successible d'être régénérer à n'importe quel moment et donc d'engendrer la perte de toutes les modifications.

Par contre il n'est pas logique que sur BaseArticleLivreForm le widget généré pour un champ de liaison soit de type hidden. Il devrait être de type select (soit une liste déroulante par défaut).

Il convient donc de régénérer les objets base avec une commande "build --all". Attention, celle-ci supprime la base de données avant de la recréer...

Merci pour ta réponse ;) j'apprends de nouvelles choses chaque jour :)
Pour l'histoire des noms d'article, fournisseur, etc à la place des Id, j'ai pu la régler finalement, il fallait rajouter une fonction __toString() dans les classes correspondantes et ça marche!!!
16/03/2011, 11h45
Michel Rotta

oui, __toString marche, mais avec des select, pas avec des hidden...

D'où ma tentative de te faire transformer tes hidden vers des select, que tu as dû faire, puisque cela marche. Le __toString() est l'étape suivante.

Mais le principale est que cela marche.:ccool:

La différence entre théorie et pratique ? La théorie c'est quant on sait pourquoi cela ne marche pas, la pratique c'est quant on ne sait pas pourquoi cela marche. A noter qu'il existe aussi la merde, quant on ne sais pas pourquoi cela ne marche pas. Et enfin, l'inconnu, quant on sait pourquoi cela marche... :mouarf:
16/03/2011, 16h59
flora806

Citation:

Envoyé par Michel Rotta

oui, __toString marche, mais avec des select, pas avec des hidden...

D'où ma tentative de te faire transformer tes hidden vers des select, que tu as dû faire, puisque cela marche. Le __toString() est l'étape suivante.

Mais le principale est que cela marche.:ccool:

La différence entre théorie et pratique ? La théorie c'est quant on sait pourquoi cela ne marche pas, la pratique c'est quant on ne sait pas pourquoi cela marche. A noter qu'il existe aussi la merde, quant on ne sais pas pourquoi cela ne marche pas. Et enfin, l'inconnu, quant on sait pourquoi cela marche... :mouarf:

Je suis tout à fait d'accord :mouarf:
l'essentiel ce que ça marche...mais avec ce projet là, ce n'est jamais fini, je passe d'une difficulté à une autre, comme c'est la première fois que j'utilise symfony, c'est pas gagné :aie:
16/03/2011, 18h06
Michel Rotta

C'est bon alors, il parait qu'à partir du dixième projet cela commence à aller mieux...:mouarf: