Admin generator : ajouter fonction de tri sur une colonne de la liste

**Herode** · 04/02/2011, 10h59

Bonjour à tous,

Soit un module d'admin généré par le doctrine:generate-admin classique. Ma page de liste propose la liste des objets et plusieurs colonnes.

Soit mon objet Machinchouette, qui a un champ configuration_id (clé étrangère vers une table Configuration).

Dans le generator.yml :

Code :

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

1
2
      list:
        display: [configuration_id]

me donne une colonne "configuration_id" avec la fonction native de tri implémentée par le pager de symfony. Bien commode mais hélas, c'est l'id qui est affichée (et non le résultat de la méthode __toString() de la Configuration).

Mais si je modifie le generator.yml :

Code :

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

1
2
      list:
        display: [configuration]

j'obtiens une colonne "configuration" avec le libellé, ce qui est bien - mais la fonction de tri a disparu, ce qui est mal.

D'où ma question : que puis-je faire pour récupérer cette fonction de tri ?

**Michel Rotta** · 04/02/2011, 11h19

Je diras qu'à priori tu ne peux pas.

Vu que tu n'affiches qu'une table et que celle-ci ne comporte que l'ID. Trier sur le _toString() implique que symfony devrait être capable de décortiquer ton code pour comprendre comment tu construits l'affichage et, de là, en déduire une méthode de tris ! Tu lui en demande beaucoup là.

Imagine une méthode _toString() sur des personnes qui retournerait : "(Société) Nom Prénom". Il faudrait que symfony soie capable de comprendre qu'il doit trier sur la société, puis le nom, puis le prénom !

Accessoirement, méfie toi d'un _toString() de ce type dans une liste, tu risques d'avoir rapidement un nombre de requête sur la BDD très important...

Si tu veux pouvoir réaliser cela, il va falloir écrire une méthode sur ton objet du modèle qui te retourne les champs que tu veux utiliser sur les deux tables en question. Et je ne sais absolument pas si le générateur d'amin est capable de s'en sortir sur ce type de requêtes "multi objets", jamais testé.

**Inarius** · 04/02/2011, 13h36

Sinon si tu veut juste afficher le "champs" configuration, tu peut utiliser la méthode suivante :

Code :

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

1
2
3
4
5
 
      list:
        display:            [configuration_id]
        layout:             stacked
        params:            %%configuration%%

Mais à ce moment la, si tu veut afficher d'autre champs, ils ne seront plus bien ranger par colonne...

**Herode** · 07/02/2011, 11h02

OK, merci pour vos réponses

En réalité, je veux afficher pas mal d'autres champs, j'ai juste simplifié la présentation du problème. Il va quand même falloir que je trouve une astuce pour régler cela, ça s'annonce pas simple mais - heureusement - pas prioritaire sur le projet actuel. Peut-être qu'en allant farfouiller dans le code du sfPager je trouverai quelque chose à bidouiller.

**Michel Rotta** · 07/02/2011, 11h10

sfPager ne gère ni le tris, ni le filtre.

Donc si tu veux farfouiller c'est dans le code du contrôleur et est, ici, auto-générer.

Il faut donc envisager de modifier le code du contrôleur et perdre une bonne partie de la souplesse d'utilisation.

Il y a peut-être une autre solution, pas très propre, pas testée... (aie pour toi ! ), utiliser les vues de la base de données, définir dans ton shema un modèle qui correspond à la vue et générer sur le model correspondant à la vue. Ceci implique de perdre la liaison entre le shema et la structure physique, les deux devant être manipulé indépendamment, adieu "build --all" et bonjour les contraintes

**Herode** · 07/02/2011, 14h47

Passer par une vue est en soi une bonne idée, j'ai utilisé ce genre de techniques à plusieurs reprises dans de gros projets pour simplifier les requêtes, mais évidemment je n'avais pas à interagir avec les contraintes de Symfony.

J'avoue que déclarer la vue dans le schema et voir des build* passer dessus ne m'inspire pas du tout confiance, ça va être un sac de noeuds terrible.

Par contre, en restant dans l'esprit de ta suggestion, il suffirait peut-être d'ajouter des colonnes "calculées" à mon modèle, un peu comme l'est la colonne slug quand on rend un objet sluggable.

Et même, en poussant un peu plus loin, de créer un comportement (behaviour) associé pour pouvoir réutiliser tout ça plus facilement car bien entendu, la question va se poser pour plusieurs objets de mon modèle. Là par contre, je m'avance peut-être car je n'ai pas encore fouillé dans le code Doctrine pour voir comment cela fonctionnait...

**Michel Rotta** · 07/02/2011, 15h00

Je pense que sans un behaviour ton système ne peux pas marcher. Par contre il serait intéressant à avoir.

Quitte a avoir un behaviour de table qui lui dise que, pour cette table, c'est de la lecture seulement et qu'il n'y a pas de sql à générer.

Et packager le tous dans un plugins