Pagination ?

[Youndaiime]

Hello ! Je suis entrain de codé un système de pagination en js.
Je voulais savoir comment vous gériez ceci ? Un librairie, à la mano, avec votre framework.

Merci

[Xenos]

Salut,

une pagination en JS ?! Wow... Je n'ai jamais entendu parler d'un tel mécanisme... C'est à la BDD de faire la pagination (au détail près de l'article "Pagination: you're doing it wrong" je crois, qui traine quelque part sur le forum). A défaut de BDD, c'est au serveur de faire ce travail (qui, ok, peut être en JS, mais je pense que si tu en es réduis à faire de la pagination en Node.JS côté serveur, c'est que t'as besoin de monter une BDD )

Quant au côté "client"... Là, je ne vois vraiment pas comment tu comptes faire une pagination avec du JS dans un navigateur?!

Du coup, je ne comprends pas la problématique...

[Dioux]

Si tu as une API qui te permet de paginer, il te suffit de faire un appel AJAX pour récupérer les données a chaque fois que tu pagines, si tu récupères tout puis que tu désires paginer, effectivement ce n'est pas une bonne solution.

[Xenos]

Et à ce compte-là, je pense que tu peux largement te simplifier la vie et dégager la partie AJAX (plus tu mettras de couches de complexité, plus ce sera chiant à maintenir à long terme). Ca te donne alors une bête page PHP (ou autre) ultra-classique, dans laquelle tu as juste à altérer la requête SQL pour demander la pagination (par "LIMIT/OFFSET" ou par "id > ..." suivant ton cas).

[Youndaiime]

J'ai dis une connerie et en plus je me suis perdu dans ce que je voulais dire. Effectivement je suis sur node et oui ma requête pour la pagination est faite en BDD, ce que je cherchais à savoir c'est comment dans votre vue vous geriez cette pagination, dynamiquement? Où vous rechargez votre page à chaque fois ?

[Xenos]

La pagination du plugin wordpress (catlist) fonctionne simplement en créant une liste de lien, vers chaque page. Sur Mantis aussi je crois. La liste est souvent tronquée après la page 3 voire 4 (personne ne va au-delà, la page 2 n'est parfois même pas nécessaire) car cela signifie surtout que tu n'as pas su servir à l'utilisateur ce qu'il cherchait (ie: dans un moteur de recherche ou un champ de recherche quelconque, l'utilisateur va plutôt affiner ses paramètres de recherche que browser page à page, sauf éventuellement s'il n'y a que 2 pages).

Du coup, si je devais la faire (vu que je n'ai pas eu à la coder: Mantis est out-of-the-box et le plugin catlist aussi), je la ferai simplement de la même façon: ma procédure SQL me renverrait mes lignes de données, plus un resultset donnant ou bien le nombre de page, ou bien l'existence d'une page 2 (ou d'une page 3), suivant si je décide de faire une pagination classique ou un simple indicateur "page suivante/précédente".
Côté PHP, j'aurai alors juste à renvoyer les ancres "a" correspondant à ces pages. D'autres solutions consistent juste à renvoyer le nombre total de lignes matchées par la requête (SQL_CALC_FOUND_ROWS) et le code PHP (ou JS) se charge de construire les liens correspondant à coup de modulo.

Dans certains cas (genre pour Iamanoc), j'ai purement viré la pagination (osef un peu de l'historique, et si on le voulait, alors je pars du principe qu'on veut en faire tout l'historique: je ferai alors une page "archive" qui donnera la totalité de tous les messages postés). Si je devais remettre la pagination, alors je la baserai sur les IDs (façon twitter, "messages suivants/précédents", qui seraient donc des liens générant une requête type "WHERE id < $_GET['idMax']" [Nota: le premier qui met littéralement ça dans son code mangera "La sécurité pour les nuls"... littéralement!]).