[sf 1.4.x] Generator et application auto d'un filter

[dnd888]

Bonjour tout le monde ,

Je souhaite afficher les elements de mon generator.yml par rapport à la valeur d'un champs de mon filter ,

J'ai un champs Type , si je le met à 1 cela affiche les elements de mon generator à 1 et si j'ai un champs type à 0 , cela affiche les elements de mon generator à type =0 . Je souhaiterais savoir comment faire pour que cela se fasse automatiquement ( donc sans que j'ai a mettre 1 ou 0 dans mes filters).
Mon objectif ici est que lorsque j'arrive sur la page de mon module de backend je sois tout de suite sur un tri de mes elements avec type = 0

Merci d'avance.

[PeytaWodka]

Ca peut peut-être t'aider : http://www.symfony-project.org/refer...er_06_sub_sort

[dnd888]

Désolé ca ne m'aide pas , tu m'as donné un lien qui montre le tri dans une list pas qui assigne des valeurs de filters par défaut :/

[PeytaWodka]

Désolé, une erreur de ma part, j'était parti sur le tri.
Pour mettre un filtre par défaut, je ne vois pas comment faire.

[Michel Rotta]

Regarde bien quant tu utilises le filtre. Tu vas voir que l'action du bouton filtre est un GET. Je n'ai pas la structure sous les yeux, mais cela doit ressembler à un truc du genre module/action?filtre&truc=bidule&bazarre=machin.

Il te suffit de générer le même get et d'appeler ton module avec. Tu va afficher tes données avec le filtre.

Par contre, le données resteront filtrable, un utilisateur va donc pouvoir modifier le filtre par après, ce qui peut, suivant les cas, être un avantage ou un handicap.

[dnd888]

Je m'y connais mal en backend , quel est l'endroit ou tu met le code de l'appel du filtre ?

Et si je hide ce filtre , il pourra quand meme ?

[Michel Rotta]

Jamais essayé. Normalement cela pourrait marcher. Mais la donnée sera visible dans le get, et donc susceptible de modification.

La seul fois où j'ai dû imposer de type de filtre (je ne sais plus si c'était pour un auto-généré, mais cela devrait fonctionner pareil) j'ai créé une méthode dans le modèle qui retournait le query plutôt que de laisser la méthode de base qui retourne toute la table. Dans le generator.yml, tu peux préciser la méthode du modèle à utiliser. En parallèle, tu stockes dans l'objet utilisateur, dans un paramètre, la valeur que tu veux retrouver, forcer. Dans ta méthode, tu crées le query en te basant sur la valeur stockée dans ton objet user.

Donc, plus rien de visible et impossible de le modifier.

[Maerlyn31]

Un article que j'ai lu il n'y a pas longtemps, et qui pourra sans doute t'intéresser :

http://www.lexik.fr/blog/symfony/sym...on-backend-958 => partie "Les filtres au service de la navigation"

[Mordri]

J'ai eu une question similaire y'à pas longtemps, tu doit pouvoir l'adapter facilement

http://www.developpez.net/forums/d10...ters-champ-id/

Si le filtre est hide ça fonctionne aussi.

Si tu veux qu'automatiquement le filtre soit mis (sans passé par un autre module) n'utilise pas les flash et utilise directement setFilters (les flash servants à transmettre une information le temps d'une requête)

[dnd888]

Merci pour cet information ,

ca marche mais pour cela je dois charger 2 fois la page , comment faire pour que ca fonctionnes au premier chargement ? ( j'utilise executeIndex ) , si je fais un preExecute ca va marcher mais je ne pourrais plus modifier les options de filtre ce qui ne me convient pas ,

Merci d'avance

[dnd888]

j'ai tenté un $this->redirect mais ca me crée une boucle de redirection , aidez moi je ne sais plus quoi faire ...

[Mordri]

alors la je ne sais pas trop pourquoi.

Montre un peu tes codes histoire d'essayer de voir (je dit bien essayer je suis aussi un débutant avec sf)

[Michel Rotta]

Il faut deux routes et deux adresses !

Une pour le retour du form qui met en forme vers...

L'autre pour afficher les données...

Si tu fais, comme je le soupçonne, un redirect() vers la même route, ça va tourner en rond !

[Nico_F]

En effet, l'action du filtre est un GET, le souci c'est qu'il n'y a aucun paramètre visible dans l'URL avec les filtre de l'admin gen'.

Par contre tu peux retrouver dans ta debug toolbar les filtres appliqués dans le USER dans l'attributeHolder. Pour ton module, au premier chargement tu auras un attribut "nomDuModule.sort [null, null]". Dès le premier filtre que tu appliqueras, il y aura en plus un attribut "nomDuModule.filters" avec tous les champs sur lesquels il est possible de faire un filtre.

En reprenant cette structure, ne serait-il pas possible d'appliquer ton filtre par défaut en attaquant directement cet attribut "nomDuModule.filters" dans la session utilisateur, quitte à le créer s'il n'existe pas encore ? (en prenant bien soin de respecter la structure de celui-ci évidemment)