Bonjour à tous
j'ai développé une classe PHP permettant d'afficher sous forme de liste les résultats d'un requête.
très simple à utiliser, elle gère le tri sur les colonnes, la pagination,
le contenu des cellules est entièrement paramétrable et peut être généré par des fonctions personnelles (calcul, traitements de chaine...)
le tout mis en forme entièrement pas CSS
 
pour en savoir plus : http://www.romualb.com/2009/09/27/ [...] istes.html

la mise en session , c'est mal ( que se passe t il si il y a 2 listes sur la pages, ou deux onglets ouvert du meme site ?

les noms de fonction mi anglais, mi français, c'est mal

qu'en est il de la gestion des erreurs ? du choix de la base de données à requeter ?

pour paginer une requetes, il y a de bien meilleures solutions que de tout ramener en mémoire ( LIMIT x,y)

As tu regardé du côté des orm pour concevoir quelque chose de réutilisable hors de ton contexte particulier ?

Merci pour tous ces commentaires constructifs (ou pas).
 

c'est vrai que je pourrais proposer de passer les arguments de tri et de pagination dans l'url, mais il y a aussi des arguments contre (perte des arguments en cas de changement de page et retour sur la liste...)
 

si tu veux
 

la classe est indépendante de la base de données. Le traitement SQL se fait en amont, le résultat est passé à la classe.
 

lesquelles ?

si vraiment u préfère la session , prevoit le truc pour qu'il puisse stockjer plusieurs "requetes"

donc si je te passe un datasaet issu de sql server ou de postgresql , tu saura le gérer ?

pour paginer, il vaut largement mieux paginer au niveau de la requete ( syntaxe LIMIT  pour mysql par exemple) , pour ne pas tout charger . Mais ça implique de ne plus être aussi indépendant de la bdd que ce que tu le souhaiterai

ça c'est valide uniquement si ta base de données sait le faire sans une prise de tête monstrueuse.

Tu les maintiens en rendant ton site "pagination-aware". Parce que je suis d'accord avec flo850: un site qui pète parce que des paramètres de locaux sont stockés en session (qui est par définition globale) c'est crispant.

Sans compter que stocker ces trucs en session signifie qu'il n'y a pas de liens, ça flingue potentiellement la possibilité de le cacher, et ça empêche les visiteurs de partager la page.

Rends la classe db-aware alors (ou, encore mieux, utilise des itérateurs PHP et non des arrays), parce que devoir récupérer 100000 enregistrement pour n'en afficher que 10, c'est pas exactement efficace comme méthode.

Sinon, niveau API c'est assez horrible:

• Des paramètres obligatoires (les données à paginer par exemple) qui sont associés avec un setter alors que ça devrait être fait dans le constructeur (qui devrait également gérer la taille des pages, avec des paramètres par défaut si besoin)
• Comme déjà mentionné par flo850 le style de codage est horrible (mélanges entre camelCased et underscore_separated, préfixe m_ qui n'a aucun intérêt en PHP, mélange de français et d'anglais, …)
• La classe fait beaucoup trop de choses, une classe qui fait de la pagination n'a pas à s'occuper de l'ordre de tri, ta classe devrait être séparée en une demi-douzaine (au moins). Autres trucs qu'une classe de pagination n'a pas à faire: s'occuper de la manière dont ses paramètres sont stockés (surtout si c'est pour les hardcoder dans la session), s'occuper du formattage à l'affichage, … ça manque de composition.

Globalement, je te suggère de regarder comment d'autres ont résolu le problème. le Paginator django a une API pas dégueu et fonctionne globalement bien, ça peut être un point de départ intéressant.

je rejoin flo et Masklinn, je rajouterai qu'un systeme de template est bien plus pratique, le html au milieu de la class c'est pas top,  

des templates plus ou moins standardiser y'en a pas mal (ex : http://developer.yahoo.com/ypatter [...] arch.html),

et niveau autre API en complement regarde aussi vers Zend Paginator : http://framework.zend.com/manual/f [...] nator.html