ProxyEPN

Modifications publiées sur le svn (r235) :
- Ajout de méthodes à l'objet sfGuardUserProfilePeer pour retourner un 'pager' au lieu de la liste des users
- Modification des actions du module user pour appeler utiliser ces nouvelles méthodes
- Modification du template IndexSuccess pour exploiter la pagination de la liste en ajoutant des éléments de navigation dans le formulaire (choix de la page et de la longueur des pages)

Notes :
- La pagination s'applique pour tous (pas uniquement en mode admin) mais les éléments de navigations ne s'affichent que si nécessaire (transparent si les résultats tiennent sur une seule page)
- Par défaut, les pages sont limitées à l'affichage de 50 utilisateurs

TODO :
- Gérer le tri des colonnes par une nouvelle requête en passant l'ordre à l'objet sfPropelPager, le système actuel en javascript ne permettant de trier que les éléments de la page affichée

Modifications publiées sur le svn (r247) pour implémenter le tri par colonne sur les listes paginées.

L'intégration du composant sfPropelPager implique que seule une partie des résultats (la page en cours) est envoyée au navigateur, rendant inefficace le tri dynamique par jquery.tablesorter.js. Cependant l'utilisation du module javascript est conservé pour les raisons suivantes :

• Si suite à la pagination les résultats tiennent sur une seule page, le tri en Javascript est tout à fait valide. Il serait donc dommage de s'en priver alors qu'il permet d'économiser les requêtes au serveur.
• Même s'il n'est pas capable de trier sur l'ensemble des pages, la mise en place du tablesorter permet au moins d'appliquer le style css habituel à la liste, y compris la barre d'entête des colonnes.

La méthode mise en place s'appuie donc dans tous les cas sur le module jquery.tablesorter. Mais dans le cas où la liste tient sur plusieurs pages, ses fonctions de tri sont désactivées et les évènements onclick sur les entêtes de colonnes sont redirigés pour effectuer une soumission du formulaire en modifiant l'ordre demandé.

Celà se fait grâce à un widget particulier défini dans tablesorter nommé 'reloadPager'.
Il remplace l'action par défaut du click sur les entêtes pour utiliser le formulaire à la place.
Le nom du formulaire doit être "frmlist" (en dur dans la définition du widget dans l'include _jquery_tablesorter.php)

La colonne sur laquelle s'applique le tri est néanmoins passée à l'initialisation du tablesorter afin qu'il s'occupe lui-même d'appliquer les styles correspondant sur les entêtes. Par contre ses fonctions de tri sont rendues inopérantes en redéfinissant sa fonction textExtraction afin qu'il ne touche pas à l'ordre des lignes tel que généré par le serveur.

Enfin, côté serveur, l'ordre de tri demandé est passé sour la forme d'un paramètre order valant le numéro de colonne, en négatif pour un tri descendant (d'où une numérotation des colonnes à partir de 1).
La correspondance entre cette indice et les colonnes à utiliser dans la requête s'effectue dans le fichier actions.class.php. Pour simplifier cette opération, une méthode utilitaire statique getOrderCrit() a été ajoutée dans la classe PeerHelper.
A défaut de pouvoir générer un début d'objet Criteria contenant les clauses 'order by' réutilisable par la suite par le sfPropelPager, getOrderCrit retourne un tableau avec les colonnes qui sera alors ajouté au Criteria du pager en temps voulu.

Notes :
- Si besoin le jquery.tablesorter.pager.js a été ajouté dans le dossier js, bien qu'il ne soit ici aucunement utilisé (il impliquerait que toutes les lignes soient retournées par le serveur ce qui n'arrange pas la charge du navigateur quand il y a beaucoup de résultats)
- Sur la liste des contacts, le tri sur les GEPN en multipage ne se fait pas sur le nom mais sur l'id, car actuellement la requête SQL utilisée ne fait pas de jointure sur les structure_group