Backend - Ajout d'une action dans l'édition

Version imprimable

Voir 40 message(s) de cette discussion en une page

Ouai je te les posterais si je ne trouve pas.

Voici ce que j'ai et je ne cromprend pas pourquoi cela ne marche pas.
action.php

Code:

1
2
3
4
5
6
7
8
 
  public function executeNewByModel(sfWebRequest $request)
  {
    $model = $this->getRoute()->getObject();
    $this->article_type = $model->copy(true);
    $this->form = $this->configuration->getForm($this->article_type);
    $this->setTemplate('new');
  }

ArticleForm.php

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
configure(){
$subForm = new sfForm();
  for ($i = 0; $i < 2; $i++) {
$composition = new ArticleComposition();
    $composition->article = $this->getObject();
    $compositionForm = new ArticleCompositionForm($composition);
    $compositionForm->setDefault('article_id', $this->object->id);
    $compositionForm->widgetSchema['article_id'] = new sfWidgetFormInputHidden();
    unset($compositionForm['article_id'], $compositionForm['quantite']);
    $compositionForm->widgetSchema['article_compose_id'] = new sfWidgetFormDoctrineChoice(array('model' => $compositionForm->getRelatedModelName('element'), 'add_empty' => true));
    $subForm->embedForm($i', $compositionForm);
}
$this->embedForm('TEST', $subForm);
}

Ceci marche.

Maintenant en modifiant un peu :
action.php:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
  public function executeNewByModel(sfWebRequest $request)
  {
    $model = $this->getRoute()->getObject();
    $this->article_type = $model->copy(true);
    $collection = new Doctrine_Collection ("ArticleComposition");
    foreach($model->getEstComposes() as $composition)
    {
      $temp = $composition->copy(true);
      $temp->article = $this->article_type;
      $collection->add($temp);
    }
    $this->article_type->estComposes = $collection;
    $this->form = $this->configuration->getForm($this->article_type);
    $this->setTemplate('new');
  }

ArticleForm.php

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
configure() {
 $subForm = new sfForm();
    foreach ($this->getObject()->getEstComposes() as $composition) {
     $composition->article = $this->getObject();
     $compositionForm= new ArticleCompositionForm($composition);
     $compositionForm->widgetSchema['article_compose_id'] = new sfWidgetFormDoctrineChoice(array('model' => $compositionForm->getRelatedModelName('element'), 'add_empty' => true));
 
     $compositionForm->setDefault('article_id', $this->object->id);
     $compositionForm->widgetSchema['article_id'] = new sfWidgetFormInputHidden();
     unset($compositionForm['article_id']);
 
     $subForm->embedForm($i++, $compositionForm);
 
   }
 
       $this->embedForm('test', $subForm);
 
}

Ce code ne marche pas

J'ai essayé en mettant

Code:

$this->getObject()->setEstComposes(new Doctrine_Collection ("ArticleComposition"));

mais cela ne change rien.

voici l'erreur :

Code:

1
2
Unexpected extra form field named "0".
Unexpected extra form field named "1".

Une idée ? Il est écrit que c'est la faute des validateurs mais je ne vois pas pourquoi dans un cas, cela marche mais pas dans l'autre.

Simplification du problème pour éviter les confusions :

schema.yml:

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
 
ArticleComposition:
  connection: doctrine
  tableName: article_composition
  columns:
    article_id:
        type: integer
        notnull: true
    article_compose_id:
        type: integer
        notnull: true
    quantite:
      type: integer
  indexes:
    art_artcompose:
      fields: [ article_id, article_compose_id ]
      type: unique
  relations:
    article:
        class: ArticleType
        local: article_id
        foreign: id
        type: one
        onDelete: CASCADE
    element:
        class: ArticleType
        local: article_compose_id
        foreign: id
        type: one
        onDelete: CASCADE
 
ArticleType:
  connection: doctrine
  tableName: article_type
  columns:
    reference:
      type: string(45)
      notnull: true
    indice:
      type: string(2)
      notnull: true
    nom:
      type: string(45)
    dimension:
      type: string(45)
    commentaire:
      type: blob
  indexes:
    refindice:
      fields: [ reference, indice ]
      type: unique
  relations:
    ArticleCompose:
      class: ArticleComposition
      local: id
      foreign: article_compose_id
      alias: composes
      type: many
      onDelete: CASCADE
    ArticleEstCompose:
      class: ArticleComposition
      local: id
      foreign: article_id
      alias: estComposes
      type: many
      onDelete: CASCADE

action.class.php

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class articleActions extends autoArticleActions
{        
 
  public function executeNewByModel(sfWebRequest $request)
  {
    $model = $this->getRoute()->getObject();
    $this->article_type = $model->copy(true);
    $collection = new Doctrine_Collection ("ArticleComposition");
    foreach($model->getEstComposes() as $composition)
    {
      $temp = $composition->copy(false);
      $temp->article = $this->article_type;
      $collection->add($temp);
    }
    $this->article_type->estComposes = $collection;
     $this->article_type->reference = $this->article_type->reference.'_NEW';
    $this->article_type->save();
    $this->form = new ArticleTypeForm($this->article_type);
    $this->setTemplate('edit');
  }
 
}

ArticleTypeForm.class.php

Code:

1
2
3
4
public function configure()
  {
    $this->embedRelation('estComposes');
  }

Ceci marche mais me force à dupliquer l'objet en base

En enlevant le save(), j'ai cette erreur :

Code:

Unexpected extra form field named "0"

27/07/2010, 13h19
mathieu44800

Pour les données hiérarchiques, mieux vaut utiliser un actAs Doctrine : "nestedSet".

Tu pourra plus aisément gérer ta composition d'articles...
29/07/2010, 16h28
butters

mais le problème des hiérarchie me forcerait à revoir la totalité de mon code du module ... Et j'ai plus trop le temps.

Peut être que s'il me reste du temps, je jetterais un coup d'oeil.
31/07/2010, 16h11
Michel Rotta
J'ai "un peu" souffert pour utiliser ton code, il a été tellement épuré qu'il n'y avait plus rien...

Bon, j'ai recréé un module et reconstruit un bout d'appli qui tourne.

Première chose, le code de la copie d'un objet et de ces relations marche, mais il est en contradiction avec l'index sur la table ArticleType. En effet, toutes recopies vient en contradiction avec l'unicité de l'index.

Deuxième chose. La liaison entre ArticleType et ArticleComposition implique que les enregistrements de la table composition doivent, eux aussi, être dupliqués lors de la duplication d'un ArticleType.

Donc de deux choses l'une :
- La liaison entre ArticleType et ArticleComposition est une liaison n-n mal implémentée (il manque une table) et on peut (peut-être) faire un article new non sauvegardé
- La liaison entre ArticleType et ArticleComposition est correctement implantée (ce qui me semble être le cas), c'est une liaison 1-n. Dans ce cas il faut dupliquer non seulement l'ArticleType, mais aussi tous les ArticleComposition qui lui sont liés... Et donc enregistrer l'ArticleType et les ArticleComposition avant toutes éditions.
On fait quoi ?
31/07/2010, 18h59
butters

ben si tu peut, envoie moi ce que tu as modifié, je le lirais et en fonction de cela, je regarderais pour faire les modifications nécessaire.

Je vais revoir ma relation N-M du coup. Et du coup je lirais tes modifications avec attention.
31/07/2010, 20h25
Michel Rotta

En fait, il n'y a pas de vraiment de modification, j'ai juste viré un paquet de code qui ne me semblait pas servir.

Mais, pour faire quelque chose qui tienne un peu la route, j'ai besoin de savoir si la relation entre les deux tables est n-n ou 1-n en gros, est-ce qu'un des élément de la table composition peut être liée à plusieurs article (sachant que si on la modifie, on modifie tous les articles aussi).

M'est avis que les "composition" d'un article sont propre à un article et que si on duplique un article, ces "compositions" ce retrouvent indépendant des "compositions" de l'article d'origine.
02/08/2010, 09h57
butters

Citation:

Mais, pour faire quelque chose qui tienne un peu la route, j'ai besoin de savoir si la relation entre les deux tables est n-n ou 1-n en gros, est-ce qu'un des élément de la table composition peut être liée à plusieurs article (sachant que si on la modifie, on modifie tous les articles aussi).

C'est une relations N-M. Un article peut être composé de 0 ou plusieurs articles et peut composée 0 ou plusieurs articles.

Citation:

M'est avis que les "composition" d'un article sont propre à un article et que si on duplique un article, ces "compositions" ce retrouvent indépendant des "compositions" de l'article d'origine.

Ben quand je fait une save dans action. Tout est bien dupliqué. Mais quand je le passe dans le formulaire. Les relations existe mais ne peuvent pas être sauvegardé.
02/08/2010, 12h11
Michel Rotta
Le problème des sauvegardes des relations vient de
Code:

1 2 3 4 5 6 7 articleType: ... indexes: refindice: fields: [ reference, indice ] type: unique
Ma question portait sur la relation entre articleType et articleComposition.

Par contre, ta réponse m'emplit de doutes. En effet, imaginons
Code:

1 2 3 4 5 6 7 article 1 ---| article 2 ---|--> article 3 ---| |--> article 8 article 4 ---| | article 5 ---|--> article 7 ---| article 6 ---|
Si on duplique article 7, on va avoir un article 9 avec les article 4, 5 et 6 comme parents, ça, je le conçois.

Mais quid de l'article 8 ? garder comme parent les articles 3 et 7 ou va-t-il se retrouver avec trois parents 3, 7 et 9 ???

Je pense réellement que vu l'avancement est les "emmerdes" générée par la structure, tu devrais envisager d'utiliser les classe d'héritage intégrées a Doctrine. Au moins faire un test pour la duplication.

Donc, deux questions :
- quid des liaisons avec les articleComposition ?
- quid des héritages entre articleType enfants et parents ?

Alors moi je le vois plus dans l'autre sens. Exemple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
           |--> Article 2 --|--> Article5
           |                |--> Article6
           | 
Article1 --|--> Article 3
           |
           |--> Article 4 --|--> Article 7


           |--> Article 2
Article8 --|--> Article 9
           |--> Article 10

Les article de même couleurs sont unique en base.

Maintenant, si je duplique l'article 2 j'aurais :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
           |--> Article 2 --|--> Article 5
           |                |--> Article 6
           | 
Article1 --|--> Article 3
           |
           |--> Article 4 --|--> Article 7


           |--> Article 2
Article8 --|--> Article 9
           |--> Article 10

Mais :

Article11--|--> Article 5
           |--> Article6

Les article de même couleurs sont unique en base.

02/08/2010, 17h48
Michel Rotta

Ton schéma n'est pas logique.

Si l'article 2 est le même dans les deux endroits de ton schéma, pourquoi, en haut, a-t-il article 5 et 6 comme enfants, alors que dans la partie basse du schéma, il n'a pas d'enfants ?

Avec ton schéma de table, ce n'est pas gérable. Et s'il est identique, pourquoi, en fonction de ces parents, a-t-il des enfants différents ?

non ok, je pensais que c'était assez clair, c'est pour cela que je n'ai pas copier coller. Autant pour moi. Je te le refait (les articles de même couleur ne sont qu'une seul fois en base):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
           
           |--> Article 2 --|--> Article 5
           |                |--> Article 6
           | 
Article1 --|--> Article 3
           |
           |--> Article 4 --|--> Article 7


           |--> Article 2 --|--> Article 5
           |                |--> Article 6
Article8 --|--> Article 9
           |--> Article 10

Mais si je duplique l'article 2:

Article11--|--> Article 5
           |--> Article6

J'ai, enfin, compris !

Tu as une relation de type n-n réflective avec un attribut (quantité)...

M'a fallu le temps, désolé.

Donc, les tables réflectives et autre arbres possibles avec doctrine ne marcherons pas. Oublions les.

Le schéma revu, simplifié et corrigé. Il faut voir si les nom : ArticleEstComposes et ArticleComposes sont sur la bonne relation. Un truc, sauf exception (et ici on n'est pas dedans), on ne définit une relation que d'un côté de la relation, d'où la suppression des définitions sur ArticleType. Autre chose, j'ai refais l'index sur ArticleType, en lui rajoutant l'Id pour ne plus avoir de problème de recopie d'objet, et j'ai changé l'index unique de la table ArticleCompose en une clef primaire, plus adapté et plus performante pour ce cas.
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 # Article Composition ArticleComposition: connection: doctrine tableName: article_composition columns: article_id: type: integer notnull: true primary: true article_compose_id: type: integer notnull: true primary: true quantite: type: integer relations: article: class: ArticleType local: article_id foreign: id foreignAlias: ArticleEstComposes element: class: ArticleType local: article_compose_id foreign: id foreignAlias: ArticleComposes #Article Type ArticleType: connection: doctrine tableName: article_type columns: reference: type: string(45) notnull: true indice: type: string(2) notnull: true nom: type: string(45) dimension: type: string(45) commentaire: type: blob indexes: refindice: fields: [ reference, indice, id ] type: unique
Je regarde le code pour la copie d'un article et de ces dépendances.

Je te confirme qu'il n'est pas possible de copier sans inscrire dans la base de donnée et que la création par duplication sera, en fait, une édition de l'article recopié.

J'ai viré les CASCADE sur les suppressions. J'ai un peu peur d'un effet de boule de neige dans le genre (partant de ton shéma), je supprime l'article 11, qui supprime les articles 5 et 6, qui supprimes l'article 2, qui supprime l'article 1 et 8 qui suppriment les articles 3,9,10 et 4 qui entraine 7.

Et la base est vide !!!

Je pense qu'il va falloir gérer les suppression à la main et envisager une solution pour trouver les articles orphelins.

03/08/2010, 11h35
butters

Merci beaucoup, je vais testé cela rapidement.

Oui ok pour le CASCADE, je n'y ai pas du tout pensé. Il faudrait que je mette le cascade que sur une relations non ? Je supprime l'article, il me supprime que les enregistrement dans la composition. Je fait cela comment? Dans quel cas je le met?

Citation:

Je te confirme qu'il n'est pas possible de copier sans inscrire dans la base de donnée et que la création par duplication sera, en fait, une édition de l'article recopié.

Donc je suis obligé de faire un save avant, c'est bien cela ?
Si oui, je suis donc obligé de faire comme le test que j'avais fait genre mettre le nom : getNom().'_NEW' ?
Si non, ben je vais devoir recommencer les recherches
03/08/2010, 12h40
Michel Rotta

On peut mettre une cascade oui.

Ou gérer manuellement en fonction du fait que l'article enfant à où non un autre parent. Si oui, on le garde et on supprime juste lien, si non, on le supprime. A voir en fonction de la manière dont tu comptes gérer. Il faudra alors surcharger la méthode delete() de l'objet du modèle ArticleType.

Le nom de l'article peut rester le même, vu qu'il n'est dans aucunes relations ou index unique (note, je comprend aussi le problème que posait l'index unique sur (reference, indice) que j'ai modifié en rajoutant (id). Effectivement, s'il doit rester unique sur reference, indice, il faut repenser la procédure de copie.

On pourrait alors envisager une procédure de copie en deux étapes, passant par un formulaire intermédiaire, non lié, qui demanderait le nouveau nom et/ou le nouvel indice de l'article à créer, vérifierait l'unicité (validateur) de l'information, puis, une fois cela validé, copierait les relations avec les articles enfants.

Question, dans ton exemple, lors de la copie de article 2 en article 11 l'article 11 devient racine d'une nouvelle arborescence. Est-ce le fonctionnement normal, ou un cas exceptionnel, est-ce que lors de la duplication, on ne copie pas, volontairement, les liaisons vers les articles parents ?
03/08/2010, 16h08
butters

En faite, il faudrait juste que la relation avec l'article composition disparaisse, c'est tout. C'est sur quel relations qu'il faut que je le mettent. C'est bien sur article ?

Oui, le nom de l'article est le même. Quand je fait un copie / save / edit. Je modifie la référence en ajoutant _NEW pour pas me faire jeter par l'unicité.

L'idée du formulaire en deux étapes me plaît bien mais je ne sais pas du tout comment m'y prendre.

Oui l'article 11 deviens racine. Si l'utilisateur souhaite dupliquer plus haut, il dupliquera puis enlèvera les compositions inutile.

1 pièce(s) jointe(s)

Bon, le code qui marche. Ca va être long...

Le shema final (avec l'index revenu sur deux champs seulement)

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
 
# Article Composition
ArticleComposition:
  connection: doctrine
  tableName: article_composition
  columns:
    article_id:
        type: integer
        notnull: true
        primary: true
    article_compose_id:
        type: integer
        notnull: true
        primary: true
    quantite:
      type: integer
  relations:
    article:
        class: ArticleType
        local: article_id
        foreign: id
        foreignAlias: ArticleEstComposes
    element:
        class: ArticleType
        local: article_compose_id
        foreign: id
        foreignAlias: ArticleComposes
 
#Article Type
ArticleType:
  connection: doctrine
  tableName: article_type
  columns:
    reference:
      type: string(45)
      notnull: true
    indice:
      type: string(2)
      notnull: true
    nom:
      type: string(45)
    dimension:
      type: string(45)
    commentaire:
      type: blob
  indexes:
    refindice:
      fields: [ reference, indice ]
      type: unique

Je suis parti sur un module généré par :
symfony doctrine:generate-module frontend article ArticleType

Ici suivent les modifications au différents fichiers.

Fichier : apps/frontend/config/routing.yml
J'ai rajouté deux route, une pour le module généré ci-dessus et une pour gérer la duplication. Pourquoi nbm ? heu, bon, ça peut être changé !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
article:
  class: sfDoctrineRouteCollection
  options:
    model: ArticleType
  param:
    module: article
 
article_nbm:
  class: sfDoctrineRoute
  url: /article/:id/dupliquer
  options:
    model: ArticleType
    type: object
  requirements:
    sf_method: [ get, post ]
  param:
    module: article
    action: nbm
 
...

J'ai un peu joué sur l'affichage des objets, c'est plus fun et compréhensible.

Modification de l'action.class.php, pour l'édit d'un article

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
    public function executeEdit( sfWebRequest $request )
    {
        // modifier pour butter
        $articleType = $this->getRoute()->getObject();
        $this->articleId = $articleType->getId();
        $this->form = new ArticleTypeForm( $articleType );
 
        // récupération des enfants
        $this->enfants = $articleType->getEnfants();
 
        // récupère les parents
        $this->parents = $articleType->getParents();
    }

Modification du ArticleType.class.php pour récupérer les familles :

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
 
class ArticleType extends BaseArticleType
{
 
    /*
     * Fonction pour butter
     * Récupération de la liste des enfants de l'article
     * @return array liste des enfants et quantités
     */
    public function getEnfants()
    {
        $q = Doctrine_Query::create()->
                from('ArticleComposition c, c.element e')->
                where('c.article_id = ?', $this->getId() );
        return $q->execute(array(), Doctrine_Core::HYDRATE_SCALAR);
    }
 
    /*
     * Fonction pour butter
     * Récupération de la liste des parents de l'article
     * @return array lites des parents
     */
    public function getParents()
    {
        $q = Doctrine_Query::create()->
                from('ArticleComposition c, c.article p')->
                where('c.article_compose_id = ?', $this->getId());
        return $q->execute(array(), Doctrine_Core::HYDRATE_SCALAR);
    }
}

Et un coup sur le template en édit de l'article.

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
 
...
<?php echo link_to('Dupliquer', '@article_nbm?id=' . $articleId ) ?>
 
<div id="enfants" class="composants">
    <?php if ($enfants): ?>
    <h2>Enfants</h2>
    <table>
        <thead>
            <tr>
                <th>Reference</th>
                <th>Quantité</th>
                <th>Options</th>
            </tr>
        </thead>
        <tbody>
            <?php foreach ($enfants as $enfant): ?>
            <tr>
                <td><?php echo link_to($enfant['e_nom'], '@article_edit?id=' . $enfant['e_id']) ?></td>
                <td><?php echo $enfant['c_quantite'] ?></td>
                <td>.</td>
            </tr>
            <?php endforeach; ?>
        </tbody>
    </table>
    <?php endif; ?>
</div>
 
<div id="parent" class="composants">
    <?php if ($parents): ?>
    <h2>Parents</h2>
    <table>
        <thead>
            <tr>
                <th>Reference</th>
                <th>Options</th>
            </tr>
        </thead>
        <tbody>
            <?php foreach ($parents as $parent): ?>
            <tr>
                <td><?php echo link_to($parent['p_nom'], '@article_edit?id=' . $parent['p_id']) ?></td>
                <td>.</td>
            </tr>
            <?php endforeach; ?>
        </tbody>
    </table>
    <?php endif; ?>
</div>

Primaire mais un bon début. Reste à insérer deux formulaires pour ajouter des parents et des enfants ainsi que des liens pour supprimer les liaisons.

Le liens pour la duplication est déjà dans le formulaire. Le code pour la liaison dans le fichier action.class.php

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
 
    public function executeNbm( sfWebRequest $request )
    {
        //Vérifie que l'id est présent, récupère l'article et vérifie que l'article existe
        $this->forward404If( !$request->hasParameter( 'id' ) );
        $this->a = Doctrine_Core::getTable( 'ArticleType' )->findOneById( $request->getParameter( 'id' ) );
        $this->forward404Unless($this->a);
 
        // Initialise le formulaire intermédiaire de changement de nom
        $this->form = new ArticleDupliqueForm( array(
                    'reference' => $this->a->getReference(),
                    'indice' => $this->a->getIndice()
                        ) );
 
        // Si le formulaire est en POST, c'est un retour, on lie les données et vérifie qu'il est valide
        if ( $request->getMethod() == "POST" )
        {
            $this->form->bind( $request->getParameter( $this->form->getName() ) );
            if ($this->form->isValid( ))
            {
                // Il est valide, on peut créer la duplication et renvoyer sur le nouvel article.
                $NewId = ArticleTypeTable::duplique($request->getParameter('id'), $this->form->getValue('reference'), $this->form->getValue('indice'));
                $this->redirect('article_edit', $NewId);
            }
        }
        // rien ? Et bien on va afficher le template alors.
    }

Le code de duplication dans l'objet lib/model/doctrine/ArticleTypeTable.class.php

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
 
class ArticleTypeTable extends Doctrine_Table
{
 
    public static function getInstance()
    {
        return Doctrine_Core::getTable( 'ArticleType' );
    }
 
    /*
     * Function pour Butter
     * Duplication d'un article après validation des paramètres
     * @param integer $id L'id de l'article a dupliquer
     * @param string $reference La reference du nouvel article
     * @param string $indice L'indice du nouvel article
     *
     * @return integer L'id du nouvel article.
     */
 
    public static function duplique( $id, $reference, $indice )
    {
        // Récupère l'article d'origine
        $q = self::getInstance()->createQuery( 'a' )->where( 'a.id = ?', $id );
        $ArtOld = $q->fetchOne();
 
        // Création du nouvel article
        $ArtNew = new ArticleType();
        $ArtNew->
                setReference( $reference )->
                setIndice( $indice )->
                setNom( $ArtOld->getNom() )->
                setDimension( $ArtOld->getDimension() )->
                setCommentaire( $ArtOld->getCommentaire() )->
                save();
 
        // Récupération de la liste des enfants et création des nouvelles liaisons
        foreach ( $ArtOld->getArticleEstComposes() as $ArtCompoOld )
        {
            $ArtCompoNew = new ArticleComposition();
            $ArtCompoNew->
                    setArticleId( $ArtNew->getId() )->
                    setArticleComposeId( $ArtCompoOld->getArticleComposeId() )->
                    setQuantite( $ArtCompoOld->getQuantite() )->
                    save();
            $ArtCompoNew = null;
        }
        return $ArtNew;
    }
 
}

J'allais oublier, le formulaire de vérification du nom et de l'indice, il est basé sur sfFormSymfony et ne dépend pas de la base de donnée
lib/form/ArticleDupliqueForm.class.php

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
 
class ArticleDupliqueForm extends sfFormSymfony
{
  public function configure()
  {
    $this->setWidgets(array(
      'reference'   => new sfWidgetFormInputText(),
      'indice'      => new sfWidgetFormInputText(),
 
    ));
 
    $this->setValidators(array(
      'reference'   => new sfValidatorString(array('max_length' => 45)),
      'indice'      => new sfValidatorString(array('max_length' => 2))
    ));
 
    $this->validatorSchema->setPostValidator(
      new sfValidatorDoctrineUnique(array('model' => 'ArticleType', 'column' => array('reference', 'indice')))
    );
 
    $this->widgetSchema->setNameFormat('article_duplication[%s]');
 
    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);
  }
 
  public function getModelName()
  {
    return 'ArticleDuplication';
  }
 
}

On note que l'Id d'origine ne transite pas dans le form, il circule dans le lien http, un des plus de symfony, on peut avoir un retour en POST qui récupère un plus d'informations grace à l'url et donc un mixte avec un GET.

Le template pour le formulaire intermédiaire
nbmSuccess.php

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
 
<?php use_stylesheets_for_form($form) ?>
<?php use_javascripts_for_form($form) ?>
 
<h1>Duplication d'article</h1>
 
<form method="post" action="<?php echo url_for('@article_nbm?id=' . $a->getId() )?>" >
  <table>
    <tfoot>
      <tr>
        <td colspan="2">
          <?php echo $form->renderHiddenFields(false) ?>
          <input type="submit" value="Dupliquer" />
        </td>
      </tr>
    </tfoot>
    <tbody>
      <?php echo $form->renderGlobalErrors() ?>
      <tr>
        <th><?php echo $form['reference']->renderLabel() ?></th>
        <td>
          <?php echo $form['reference']->renderError() ?>
          <?php echo $form['reference'] ?>
        </td>
      </tr>
      <tr>
        <th><?php echo $form['indice']->renderLabel() ?></th>
        <td>
          <?php echo $form['indice']->renderError() ?>
          <?php echo $form['indice'] ?>
        </td>
      </tr>
    </tbody>
  </table>
</form>

Normalement, je n'ai rien oublié.

La duplication fonctionne. On peut choisir le nom et l'indice et ils sont vérifiés. Le danger avec l'ajout d'un "_new" est que si l'utilisateur ne modifie pas le nom, la deuxième duplication du même article va générer une erreur dans la base, difficilement récupérable.

Je joint la totalité de "l'application" (sauf symfony) en pièce jointe.

Bonne chance pour la suite
Michel

05/08/2010, 11h40
butters

Waow, je pensais pas que tu allait allez aussi loin.

En tout cas, je te remercierai jamais assez pour le temps que tu as perdu à m'aider.

Je testerais cela dès que je pourrais (je suis en train de faire une "semi-notice") Je pense que d'ici lundi j'aurais pu tester. Genre ce week-end.

merci encore,
05/08/2010, 13h29
Michel Rotta

La question était complexe et large

La réponse ne pouvait que taper un peu partout aussi
10/08/2010, 14h04
butters

J'ai pas encore eu le temps de finir toute l'intégration du code mais il y a un élément qui m'échappe.

Dans la table ArticleComposition, tu as mi les 2 identifiant en clé primaire, ce que je trouve normal et c'est ce que j'aurais fait en temps réel. Mais pour symfony, c'est pas plus simple de mettre un seul identifiant et de mettre une index unique prenant les deux identifiant ?

Pourquoi met-on la relation que d'un seul côté ? Si on ne met pas de foreignAlias, il n'y a pas de problème, si ?

Voir 40 message(s) de cette discussion en une page