[sf 1.4.x] Lier deux liste avec les filtres symfony [Résolu]

[jotatan]

Bonjour,
Es ce-que quelqu'un pourrais me dire comment lier deux listes avec les filtres symfony sans ajout du code JavaScript.

En fait j'ai les groupes dans ma première liste, et les utilisateurs dans la deuxième. La deuxième liste doit être remplir selon le choix de la premier.
Et lors de la sélection d'un utilisateur dans la deuxième liste il doit y avoir l'appel d'une action de mon contrôleur pour afficher un résultat.

Comment faire tous ça sans JavaScript.

[Michel Rotta]

Ca ne doit pas être trop compliqué.

Tes deux listes sont liée à une table ? Deux tables ?

Les données retournées sont-elle elle-même reliées à un enregistrement d'une troisième table ?

Il y aura donc, sur ton form, un bouton à proximité de la première liste pour remplir la deuxième, est-ce ça l'idée ?

Y a-t-il d'autres champs sur ton form ? Si oui, y a-t-il des validator qui risquent de ce fâcher s'il revient vide ?

Ceci afin de cerner mieux le problème.

[jotatan]

- Mes listes sont lies à deux tables (Nom des tables: groupe et utilisateur) Ces tables sont lies entre elles par une clé étrangère (id_groupe) dans la table utilisateur.

- Oui, mes données retournées seront utiliser comme prédicat pour récupérée des données dans une autre table. (Je récupère en fait dans une table affectations, tous les tâches affecter à un utilisateur).

- Pas de bouton pour remplir la deuxième liste. Le remplissage doit se faire lorsque on sélectionne le groupe. Et pareil lorsque on sélection l'utilisateur (gère requêtes AJAX).

- Pour l'instant pas de validateur.

[Michel Rotta]

Juste pour fixer.

Les données récupérées de ces deux listes ne sont pas utilisées dans un enregistrement directement. Le form qui les récupère permet de monter un filtre pour d'autres données ?

Ne pourrait-on pas monter cela dans un form de type filter ?

Tu veux que le changement dans la première liste lance automatiquement le ré affichage de la page, sans JS. C'est impossible hos JS, il faut passer par un bouton et une manœuvre de l'utilisateur, c'est peut-être ton blocage. Après, rien n'empêche si le JS est actif de masquer le bouton et changer le comportement de la liste.

[jotatan]

Non, Les données récupérées de ces deux listes ne sont pas utilisées dans un enregistrement directement.

Pas de filtre pour le Form.

J'aimerais monter tous ça avec les filtres déjà crées par symfony mais je vois pas comment les utiliser. Et le tutoriel Joobet ne parle pas assez.

[Michel Rotta]

Il n'y a pas de réel tutoriel sur les filtres. En pratique c'est très proche des form, sauf qu'il y a des méthodes qui permettent de générer la partie querry d'une requête doctrine (ou propel).

Donc, pour notre partie de gestion des deux listes, que l'on soit sur un form ou un filter, la procédure sera la même.

Affichage du form la première fois. La liste 1 est remplie, la 2 vide.
Lors du retour, on vérifie le bouton qui a renvoyé
si le bouton est celui qui demande d'afficher la deuxième liste et en fonction de la valeur de la première, on renvoie la deuxième avec une requête paramétrée. Le problème est que je ne vois pas, pour l'instant, de méthode propre pour renvoyer, il faudrait que je monte un test, je vais essayer ce soir, si non, ce sera pour l'année prochaine

[Michel Rotta]

Pas simple la solution, mais intéressante.

La difficulté vient du fait qu'il n'est pas possible de faire passer simplement un argument à doctrine pour savoir sur quel élément de la liste 1 on se trouve. Après avoir tourné le problème dans tous les sens, je n'ai trouvé que le stockage temporaire en flash sur l'objet de l'utilisateur qui permette d'y arriver. Cette méthode ne me plais pas, mais elle à au moins la délicatesse de fonctionner.

Un petit exemple basé sur des département et des régions.

Le shema.yml pour l'exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
region:
  columns:
    nom:
      type:         string(40)
      unique:       true
 
departement:
  columns:
    id:
      primary:      true
      type:         integer
      autoincrement: false
    nom:
      type:         string(40)
      unique:       true
    region_id:      integer
  relations:
    region:
      foreignAlias: departements

Parce que je suis bon, un peu de fixature pour peupler la chose :

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
 
region:
  regAlsace:
    nom: Alsace
    departements:
      dep68:
        id: 68
        nom: Haut-Rhin
      dep67:
        id: 67
        nom: Bas-Rhin
  regAquitaine:
    nom: Aquitaine
    departements:
      dep24:
        id: 24
        nom: Dordogne
      dep33:
        id: 33
        nom: Gironde
      dep40:
        id: 40
        nom: Landes
      dep47:
        id: 47
        nom: Lot-et-Garonne
      dep64:
        id: 64
        nom: Pyrénées-Atlantique
  regAuvergne:
    nom: Auvergne
    departements:
      dep03:
        id: 3
        nom: Alier
      dep15:
        id: 15
        nom: Cantal
      dep43:
        id: 43
        nom: Haute-Loire
      dep63:
        id: 63
        nom: Puit-de-Dôme
  regBasseNormandie:
    nom: Basse Normandie
    departements:
      dep14:
        id: 14
        nom: Calvados
      dep50:
        id: 50
        nom: Manche
      dep61:
        id: 61
        nom: Orne

Faudra un jour qu'on se mette en ligne des petites ressources comme celle-ci, mais complète.

Il faut modifier les objets du modèle region et deptartement pour leur ajouter une méthode __toString() qui les affiches en texte dans les listes.

L'action qui permet de mettre la liste à jour. Le bouton pressé n'est pas géré.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    public function executeIndex( sfWebRequest $request )
    {
        $this->form = new doubleForm();
 
        if ( $request->getMethod() == 'POST' )
        {
            $this->form->bind( $request->getParameter( $this->form->getName() ) );
 
            if ( $this->form->isValid() )
            {
                // La ruse qui permet de stocker la valeur dans la zone flash a noter
                // qu'elle n'est renseignée que si le form est valid.
                $this->getUser()->setFlash( 'region', $this->form->getValue( 'region' ) );
            }
        }
    }

Le template qui va avec

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
 
<h1>Saisie dans deux listes</h1>
 
<form action="<?php echo url_for( 'double/index' ) ?>" method="post" >
    <?php echo $form->renderHiddenFields() ?>
    <?php if ( $form->hasGlobalErrors() ): ?>
        <h2>Erreur :</h2>
        <ul>
            <?php foreach ($form->getGlobalErrors() as $name => $error): ?>
                <li>
                    <?php echo "$name : $error" ?>
                </li>
 
            <?php endforeach; ?>
        </ul>
 
    <?php endif; ?>
    <table>    
        <tr>
            <td>
            <?php echo $form[ 'region' ]->render() ?>
            <?php echo $form[ 'region' ]->renderError() ?>
        </td>
        <td><button name="maj_list" value="maj_list">Réaffiche</button></td>
        <td>
            <?php echo $form[ 'departement' ]->render() ?>
            <?php echo $form[ 'departement' ]->renderError() ?>
        </td>
    </tr>
</table>
<button name="save" value="save" >Envoyer</button>
</form>

Plus intéressant, le form. A noter que comme c'est un form issu de rien (sfFormSymfony) on peut faire l'initialisation dans la méthode setup ou configure, au choix.

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
 
class doubleForm extends sfFormSymfony
{
 
    public function setup()
    {
        $this->disableCSRFProtection();
        $this->setWidget( 'region', new sfWidgetFormDoctrineChoice( array( 'model' => 'region' ) ) );
 
        $this->setWidget( 'departement', new sfWidgetFormDoctrineChoice(
                        array(
                            'model' => 'departement',
                            'table_method' => 'getExecRegion'
                        ) ) );
 
        $this->widgetSchema->setNameFormat( $this->getName() . '[%s]' );
 
        $this->setValidator( 'region', new sfValidatorDoctrineChoice( array( 'model' => 'region' ) ) );
        $this->setValidator( 'departement', new sfValidatorDoctrineChoice( array( 'model' => 'departement' ) ) );
    }
 
    public function getName()
    {
        return 'double';
    }
 
}

La seul ruse est dans la définition du widget département qui fait appel à un argument table_methode pour indiquer la méthode de l'objet departementTable qui sera utilisée pour récupérer les données.

La méthode sur departementTable

Code :

1
2
3
4
5
6
7
8
9
10
 
    public static function getExecRegion()
    {
        $user = sfContext::getInstance()->getUser();
        $t = departementTable::getInstance();
        $q = $t
                        ->createQuery( 'd' )
                        ->where( 'd.region_id = ?', $user->getFlash( 'region', 1 ) );
        return $q->execute();
    }

Le getFlash récupère la valeur saisie précédemment. Le peuplement du widget s'exécute lors du render de celui-ci, donc après le passage dans le contrôleur. De plus le getFlash à pour effet de supprimer la valeur du conteneur du user, donc il n'y a rien qui sort de l'instance pour se balader dans la session.

On pourrait gérer la valeur à donner si le paramètre region n'est pas renseigné dans le flash, ce qui arrive au premier affichage du form, mais c'est dépendant de l'application.


J'espère que cela répondra à ta question.

[jotatan]

Merci beaucoup, ça réponds à ma question et me donne des idées pour la suite. Encore merci.

[Michel Rotta]

Je suis tombé (sans me blesser) sur le widget :
sfWidgetFormDoctrineChoiceGrouped
qui est livré avec sfFormExtraPlugin

Tu peux y faire une liste regroupée sur un champ défini par le paramètre "group_by" dans les options.

Peut-être une autre manière de résoudre le problème des régions et départements.