Pagination difficile a utiliser ?

[mat]

Je trouve la pagination (dans les albums des gens, dans les messages) assez difficile a remarquer et a utiliser. Comme il n'y a que des liens vers les chiffres, la zone de clic est assez petite. Par ailleurs, pour aller a la page suivante ou précédente il faut en plus discerner la page actuelle (pas difficile, mais ca prend 1/2 seconde supplémentaire ).

J'ai pas nécessairement beaucoup d'idées sur le sujet, mais au moins des fleches pour faire suivant / precedent (« et » par exemple, mais en utf8 ya plein de caracteres sympa pour genre ← et →, chercher arrow dans gucharmap :), avec un accesskey dessus (je propose < et >, utilisés au moins sur linuxfr et skyblog :), ca serait pas mal.

[alexx]

J'avoue ... Si c'etait a refaire (comment ca ... c'est a refaire ? ;) ), j'utiliserais le package PEAR prevu à cette effet : http://pear.php.net/package/Pager

D'un autre coté, je ne l'ai jamais utilisé, a tester donc ... voir si on peut obtenir un résultat "pro" :)

[mat]

Tiens, je connaissais pas ce truc... ils ont vraiment tout et n'importe quoi chez PEAR :) Si t'es chaud pour tenter avec ca, pourquoi pas, je pense que juste un ptit hack pour avoir precedent/suivant ca suffit pour le moment.

[alexx]

Le truc, c'est que c'est du copié/collé a chaque fois ... Je n'avais pas reussi a l'époque a "factoriser"/"formaliser" ca pour le rentre "réutilisable" autrement que par c/c + bidouillage/adaptation.

[alexx]

Voila un premier essai avec le package PEAR Pager. J'ai pas commité, et j'attends votre avis pour l'etendre au reste de .node Pour tester : http://alexx.dotnode.net/messages/inbox?p=4 login : alexx mdp : pager

Je n'ai mis que 4 messages par page pour avoir bcp de page.

au niveau PHP, ca simplifie bien les choses :

• une requete SQL non limité (seul défaut),
• un tableau de param que l'on peut envisager global à .node,
• on contruit l'objet,
• on assigne 2 var smarty et ca roule ...

au niveau smarty, j'en parle meme pas : juste un {$pager.all} à mettre :)

[alexx]

Class Pager_dotnode hérité de Pager de PEAR

[alexx]

Au lieu de faire un parametrage global, j'ai fait une classe qui herite de Pager, voir fichier attaché à ce tichet.

[mat]

C'est mieux en effet. 2 remarques:

• Ptet ajouter un "Page :" avant ?
• Une requete SQL non limitée, ca fait tres mal non ? Qu'est ce qui t'y oblige?

[alexx]

"Page: " je l'ai enlevé justement ... je pense qu'on comprends aisément que ce sont les pages, non ? ;) Pour les requetes non limité (c'est a dire sans LIMIT), c'est Pager qui m'y oblige.

La requete renvoit toujours la liste complete des elements, et c'est pager qui ne donne que la partie du tableau a afficher suivant l'argument de page.

D'un autre coté, j'etais deja obligé de faire une requete sans LIMIT avant pour determiner le nombre de page. Mais je fesais un COUNT pour ne recuperer que le nombre d'element ... La au moins, il n'y a qu'une requete .. juste lourde en terme de transfert de données, mais pas plus complexe.

j'ai commité le changeset [19] qui integre la nouvelle classe dans tout le systeme de messagerie (3 fichiers php + 3 templates). Par contre, j'ai laissé un réglage a 4 messages par page (oublié avant de commité), a changer donc au prochain commit :)

[mat]

Le COUNT est bcp plus léger, non seulement vis a vis du transfert de données (qui ne se fait pas avec le count, donc), mais aussi en mémoire, que ca soit coté php comme sql. A mon avis c'est une tres mauvaise idée de faire une requete sans limit comme ca juste pour en afficher que une partie au final. Perso j'ai une classe Pagination custom que j'utilise dans mes projets, a qui je donne le nombre d'elements par page, le nombre total d'elements (obtenu via COUNT lors d'un truc sql), la page courante, et c'est tout. C'est moins pratique à utiliser parceque faut se taper les variables dans tous les sens, mais c'est beaucoup plus leger au final...

Les seuls cas ou c'est ptet pas indiqué d'utiliser un COUNT, c'est genre si de toutes facons tu as plein de trucs a fetcher, ou si tu as plein de group by et trucs dans le genre dans la requete. Sinon, ya aussi SQL_CALC_FOUND_ROWS() mais je pense pas qu'on puisse l'utiliser dans notre cas.

[mat]

Tiens et le pager de PEAR il fout pas d'accesskey, moi je tiens a ma navigation au clavier :)

[alexx]

bon, j'ai suivi tes conseils ... effectivement, je ne m'etais pas rendu compte de l'occupation memoire (j'ai pu voir la difference avec grosse boite .node ~600 messages) je suis passé de 1300Ko indiqué par php_mem() à 700Ko (ce que je trouve encore un peu bcp, mais bon)

La pagination a l'ancienne etait a 550Ko, mais bon on l'inclus la classe Pager que lorsqu'on en a besoin.

[mat]

Pour l'occupation mémoire, regarde aussi mysql au moment des faits, il ne sait pas que tu vas rien faire de ce que tu lui demandes de SELECTer, donc il fout tout en mémoire quelquepart, ce qu'il ne fait pas avec un simple COUNT (qui est tres rapide, surtout avec des indexes). Niveau php, on y gagne que par le fait que le tableau est plus petit en fait.

Bref, il ne reste plus que les accesskey, je regarderais si ya un moyen pas trop degueu de faire ca avec PEAR::Pager.

[mat]

Les accesskey on peut modifier une variable sensée etre privée de PEAR:Pager pour les avoir, mais bon c'est relativement porc. Si j'ai pas trop la flemme je leur ferait un rapport de bug pour qu'ils ajoutent l'idee directement.

Sinon, je suis toujours pour mettre "Page:" devant, ne serait ce que pour que la pagination soit un peu plus visible encore.

[mat]

Bon apres un rapide coup d'oeil, ya des Page: des fois, et puis pas d'autres. Je corrigerais ca quand je me ferais chier tiens.