Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour,
dans un contrôleur particulier, j'affiche les enregistrements d'une table
avec des possibilités de filtrage et une navigation paginée.
Voici un extrait du code de ce contrôleur :
class HistoController extends Zend_Controller_Action { public function indexAction() { $productions = new Productions(); $db = Zend_Registry::get('dbAdapter'); if ($this->_request->isPost()) { $f = new Zend_Filter_StripTags(); $form_filter = $f->filter($this->_request->getPost('form_filter')); if (empty($form_filter)){ $form_filter = '%'; } $silo_filter = $f->filter($this->_request->getPost('silo_filter')); if (empty($silo_filter)){ $silo_filter = '%'; } } else { $form_filter = '%'; $silo_filter = '%'; } $where1 = 'formule LIKE ' . $productions->getAdapter()->quote($form_filter); $where2 = 'silo_dest LIKE ' . $productions->getAdapter()->quote($silo_filter); $order = 'prod_id DESC'; $select = $productions->select()->where($where1) ->where($where2) ->order($order); $rows = $productions->fetchAll($select); $page = Zend_Paginator::factory($rows); $page->setPageRange(5); $page->setCurrentPageNumber($this->_getParam('page', 1)); $page->setItemCountPerPage($this->_getParam('par', 15)); $this->view->productions = $page; $this->view->form_filter = $form_filter; $this->view->silo_filter = $silo_filter; }
Mon souci est le suivant, dès que je clique sur un lien vers une autre page de résultat,
je perds mes valeurs de filtre et je ne vois pas très bien comment les conserver
d'une page à l'autre.
J'ai à peu près imaginé une solution en passant mes filtres en paramètre,
mais cette idée ne me séduit guère et je préfèrerais conserver une url intacte.
Par avance merci de votre aide.
Deviltaz.
Dernière modification par deviltaz (11-02-2009 11:50:26)
Hors ligne
Salut,
Les données sont passées en post que la première fois donc c'est logique.
Tu devrais donc te tourner vers les sessions, ou pourquoi pas, balader tes paramètres en GET si ce n'est pas contraignant.
A+ benjamin.
Hors ligne
N'oublie pas que si tu balade tes paramètres en session, il sera impossible aux visiteurs de se donner une url afin de partager la page.
De même les moteurs de recherche ne pourront pas visiter les secondes pages de résultat.
J'aurais donc plus tendance à privilégier les paramètres en get dans ce genre de cas.
Hors ligne
Oui mais de toute façon les moteurs ne valident pas les formulaires en POST (Google s'y met en GET, mais bon, bof). Et ses filtres sont chargés lorsqu'il y a eu un post d'après le script.
Ca ne fait donc aucune différence. L'utilisation de la session intervient à partir du moment où les données ont été postées.
A+ benjamin.
Hors ligne
Reste toujours la possibilité de permettre aux visiteurs de copier/coller une url et de se la partager ou de la noter et de la réouvrir plus tard.
Hors ligne
Oui, après ça dépend le but de son appli
Sinon, je ne suis pas trop pour stocker l'url d'une page en plein milieu d'une pagination.
La liste des items peut évoluer et donc l'utilisateur peut lors de sa prochaine visite se retrouver sur une page qui ne contient plus ce qu'il avait auparavant.
Évidemment on ne peut pas empêcher l'internaute de le faire. Mais dans le Web 2.0 on voit de plus en plus apparaitre des fonctionnalités qui permettent justement de mémoriser les informations que l'on a à l'écran ou de faire une sélection, ou je ne sais quoi d'autre. On ne parle plus de simple marque-page.
Mais ce n'est pas le sujet ici.
A+ benjamin.
Hors ligne
Et moi je ne suis pas pour stocker les informations de recherche en session. Il suffit que celle-ci tombe pour une raison x ou y et l'utilisateur a tout perdu.
Et puis devoir faire la recherche à chaque fois que l'on réinitialise la session pour retomber sur la page, c'est bof niveau ergonomie.
Mais comme déjà dit, c'est pas le sujet.
Hors ligne
De quoi on parle là ?
Si ton rêve c'est de troller les forums, tu t'es trompé d'endroit.
Comment peux-tu résumer le fonctionnement d'une session, qui peut être gérée de mille façons depuis le code de cette manière ? Si ce n'est pour essayer d'avoir le dernier mot et dévier totalement le sujet de départ, qui est d'aider deviltaz.
Une gestion des sessions bien construite n'influence pas du tout l'ergonomie du site. Le but d'un forum n'est pas de cracher sur des solutions qu'on n'affectionne pas en en résumant le fonctionnement à un état le plus basique.
Un peu plus de tacte serait bienvenu. Nous ne sommes pas ici pour comparer la taille de nos kiki, mais pour aider d'autres personnes.
A+ benjamin.
Hors ligne
Il va falloir que tu revoie ta définition de troll je pense. Je ne fais que donner mon opinion, tout comme toi.
Libre à deviltaz par la suite de faire les choix qu'il désire pour son application.
Hors ligne
Ce n'est pas ce que je veux dire.
Tu m'as tout l'air de ne pas avoir accepté le contre-argument de ton premier message et d'insister inutilement par la suite, ce qui fait sortir totalement du sujet.
Évidemment qu'il est préférable que plusieurs personnes donnent leur avis.
Il faut simplement du tacte et déjà ne pas commencer ses phrases par des "Et moi je" qui peuvent, par écris, être très mal perçues.
Sinon, je n'ai aucune hostilité, je me méfie et tente de désarmorçer ce genre de chose dès qu'il y a un semblant de vexation.
A+ benjamin.
Edit : si un modo préfère supprimer les messages inutiles ici, c'est volontier.
Dernière modification par Delprog (10-02-2009 15:25:35)
Hors ligne
Merci de ces propositions, je vois que la question fait débat !
Je retiens donc deux solutions possibles (pour l'instant ;-))
J'étudie la doc. de Zend_Session, ne connaissant rien aux sessions tant du point de vue ZF que PHP.
La solution des paramètres m'inquiète pour l'url ainsi obtenue.
Je vous ferai part des avancés.
Hors ligne
si tu veux pas t'embeter avec des paramètres a rallonge dans ton url, rien en t'empeche de faire un cache de ta réponse SQL (avec comme id le hash de la concatenation des paramètres en post) que tu passes via un parametre en GET )
Hors ligne
L'idée du cache SQL est pas mal mais comment tu gères le rafraichissement du résultat ? Genre si un utilisateur insère une donnée entre temps. Certes, c'est un cas critique, mais Murphy veille... A mon avis il serait plus judicieux de mettre en cache la requête mais de la repasser à chaque fois.
Sinon, je comprends vraiment pas quel est le problème avec la session. Le jour où une session tombera plus vite qu'une variable en GET, j'envisagerai une alternative à son utilisation.
D'ici là, les données qui n'ont pas besoin d'être vue par des moteurs de recherche ou les utilisateurs n'ont pas grand chose à faire en GET. On parle là d'un formulaire de filtre, pas d'un identifiant de page, de catégorie ou de produit. C'est rare que je file à mes amis des URL de listes pré-filtrées quand même...
Hors ligne
keilnoth a écrit:
L'idée du cache SQL est pas mal mais comment tu gères le rafraichissement du résultat ? Genre si un utilisateur insère une donnée entre temps. Certes, c'est un cas critique, mais Murphy veille... A mon avis il serait plus judicieux de mettre en cache la requête mais de la repasser à chaque fois.
C'est a toi de déterminé la durée de vie de ton cache, celui ci peut potentiellement être vidé si un ajout de ligne a été fait. Y a une notion de tag si mes souvenirs sont bons dans Zend_Cache. Rien ne t'empeches de tracher ton cache a l'ajout et/ou modification d'une ligne. Après tu renvois sur le formulaire pour le faire re-renseigner.
keilnoth a écrit:
Sinon, je comprends vraiment pas quel est le problème avec la session. Le jour où une session tombera plus vite qu'une variable en GET, j'envisagerai une alternative à son utilisation.
Je crois que c'est une surcharge de la session un peu inutile mais bon chacun ces choix.
keilnoth a écrit:
D'ici là, les données qui n'ont pas besoin d'être vue par des moteurs de recherche ou les utilisateurs n'ont pas grand chose à faire en GET. On parle là d'un formulaire de filtre, pas d'un identifiant de page, de catégorie ou de produit. C'est rare que je file à mes amis des URL de listes pré-filtrées quand même...
La, je ne te suis pas, c'est par parcequ'une page a des parametres passés en mode GET que celle ci est accessible à un moteur de recherche.
D'une part, il faut que l'URL avec les GET soit un lien visible par le moteur pour que celui ci puisse le suivre et donc potentiellement l'indexer. Ensuite, le lien suivi peut ne pas être accessible (mécanisme de durée de vie et/ou d'authentification).
Hors ligne
Et bien le problème est résolu grâce aux ... roulements de tambours ... sessions ! ;-)
Je n'en étais pas arrivé au bon chapitre dans la lecture de ma bible (ZF : Bien développer en PHP),
et après quelques essais j'ai décidé de conserver ces valeurs de filtre grâce au mécanisme des sessions.
Merci à vous.
Hors ligne
ndesaleux a écrit:
La, je ne te suis pas, c'est par parcequ'une page a des parametres passés en mode GET que celle ci est accessible à un moteur de recherche.
Je n'ai pas dit que si tes paramètres étaient passés en GET alors ta page serait référencée. Mais que si ta page était référencée alors il était utile de passer tes paramètres utiles dans l'URL.
Au sujet de l'inutilité de la session, prenons l'exemple d'un utilisateur qui ouvre une fiche de produit depuis une liste filtrée, puis affiche des screenshots, ajoute le produit dans son panier, change la quantité, revient sur la fiche produit puis sur la liste initiale... Comment rétablir l'URL qui lui avait permis d'atteindre cette page de produits si les paramètres étaient conservés dans l'URL ? Alors que si les paramètres sont en session il suffit de les lire.
De plus, la session n'utilise pas de bande passante alors que les paramètres GET si. Il n'y a pas de petite économie comme on dit...
Mais la conjonction de ces deux solutions (GET + SESSION) est peut être encore une option à prendre en considération dans certains cas.
Bref, c'est un faux débat comme beaucoup d'autres...
Hors ligne
Pages: 1