Projet

Général

Profil

Actions

Evolution #91

fermé

Persistence de filtres

Ajouté par Grégory MARIGOT - TEICEE il y a environ 13 ans. Mis à jour il y a presque 13 ans.

Statut:
Fermé
Priorité:
Normal
Version cible:
Début:
25/02/2011
Echéance:
% réalisé:

100%

Temps estimé:
Version ProxyEPN:
TEST

Description

Pour une navigation plus pratique, il serait souhaitable que les choix de filtres soient davantage persistents entre différentes pages.

Lorsqu'ils sont appliqués, il faudrait les mémoriser dans la session web de l'utilisateur afin de continuer à en tenir compte tout le long de la navigation (que ce soit pour les réappliquer par défaut en retournant sur la page, ou pour les appliquer à d'autres filtres équivalents sur d'autres pages, voire des formulaires).

Sont principalement concernés :
  • les filtres sur GEPN/EPN et salles (la plupart des listes et certains formulaires)
  • la sélection d'un mois (listes des sessions / calendrier / historique usager)
  • la sélection d'un intervalle de dates (entre les différentes pages des stats des EPN)

Demandes liées 2 (0 ouverte2 fermées)

Lié à Evolution #105: Exports CSV et filtresFerméGrégory MARIGOT - TEICEE22/04/2011

Actions
Lié à Anomalie #113: Non prise en compte de certains filtresFerméGrégory MARIGOT - TEICEE23/06/2011

Actions

Mis à jour par Grégory MARIGOT - TEICEE il y a environ 13 ans

  • Statut changé de Nouveau à In Progress
  • % réalisé changé de 0 à 70

Modifications publiées sur le svn (r382) :

Mise en place du dispositif d'enregistrement des filtres

L'essentiel a été mis en place dans le fichier BaseFormFilterPropel dont hérite tous les filtres. Celui-ci disposait déjà d'une méthode BindWithDefault() largement employée dans les actions. A présent cette méthode se charge du "bind" des formulaires à partir : des données postées, des données persistentes, puis des valeurs par défaut. De plus elle se charge d'appeler la mémorisation des valeurs une fois le "bind" effectué.

La mémorisation prend place dans la classe myUser, grâce à la nouvelle méthode addPersistentFilters() : celle-ci prend l'attribut "filters", y ajoute les paires clé/valeur fournies, puis réenregistre l'attribut dans la session de l'utilisateur. C'est à son niveau qu'est opéré un filtre sur les clés à mémoriser, tout filtre n'étant pas pertinent en mode persistent. Les champs pris en compte sont :
  • structure_id : sélection d'un EPN ou d'un GEPN
  • room_id : sélection d'une salle
  • type_id : sélection d'un type de session
  • month : sélection d'un mois (avec année, au format YYYY-MM)
  • date_until et date_from : un intervalle de dates (cf stats)
  • pager_nbmax : nombre d'éléments par page pour le système de pagination des listes

Ainsi à chaque validation d'un formulaire de filtre contenant l'un de ces champs, leurs valeurs sont mémorisés dans la session web. Elles pourront alors être réaffectées par défaut dans un champs du même nom de tout formulaire de filtres rencontré.

Récupération des valeurs et initialisation des filtres

Si l'affectation des valeurs se fait au moment du "bind", les données sont en réalité récupérées bien plus tôt, dès la création d'un objet "filter" (au niveau du setup() de l'objet). L'intérêt est d'avoir déjà ces valeurs disponibles lors du configure() quand les widgets sont définis, pour les cas où les valeurs sélectionnées influent sur les widgets à présenter (exemple typique : le choix du sélecteur d'EPN pour établir la liste du sélecteur de salle).

Par contre, initialiser les valeurs si tôt pose un problème : les widgets n'étant pas encore définis, la liste finale des champs est encore inconnue. On pourrait se reposer sur la méthode getFields() mais rien n'assure qu'elle correspondra bien à l'ensemble des champs présentés (liste non maintenue / construction dynamique variable / "merge" de formulaires).

De plus, il est fréquent qu'une valeur mémorisée ne soit pas valide pour le formulaire actuel (ex: un numéro de salle non disponible dans le sélecteur car l'EPN sélectionné a changé). Or celà provoque une erreur de validation de la valeur au moment du "bind" et la conséquence est sévère : le formulaire n'est pas valide, toutes les valeurs "propres" sont supprimées, un getValues() retourne un tableau vide.

Il était donc nécessaire d'assouplir les formulaires de filtres :
  • Une nouvelle classe sfValidatorSchemaTolerant est utilisée. Elle hérite en tout de la classe sfValidatorSchema, à l'exception de la méthode doClean() : lorsqu'une valeur n'est pas validée celà ne génère pas d'erreur. Ainsi le formulaire est au moins rempli avec les valeurs "propres" disponibles.
  • L'option 'allow_extra_fields' du validator schema permet quant à elle de tolérer la présence de valeurs pour des champs n'existants pas dans le formulaire. Il est alors possible de charger toutes les données mémorisées et de les passer au "bind" sans soucis. Les valeurs concernées seront prises, les autres ignorées.

Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans

  • Statut changé de In Progress à Résolu
  • % réalisé changé de 70 à 100

Correction pour rendre moins persistents les filtres...

Modifications publiées sur le svn (r389) :

Une fois un formulaire de filtres initialisés, un champs vide par défaut et un champs validé avec le choix vide ne sont pas différenciables. En refusant d'enregistrer dans les filtres persistents un choix valant NULL, les choix forcés remis à vides n'étaient plus pris non plus (il devient alors impossible de supprimer un filtre persistent).

Donc les filtres ayant NULL comme valeur doivent aussi être enregistrés, permettant de les remettre à zero.
Par contre, pour ne pas rendre persistent tous les choix par défaut des formulaires, ceux fournis dans la requêtes sont conservés indépendament pour être les seuls aptes à devenir persistents.

Application des filtres persistents dans les formulaires

Modifications publiées sur le svn (r414) :

L'objet formulaire de base s'occupe de récupérer l'ensemble des filtres persistents dans la propriété persistent_filters.

Ainsi la plupart des champs de formulaire qui correspondent à des filtres peuvent utiliser la valeur persistente - si elle existe - pour définir leur valeur par défaut.

Ceci a été appliqué sur la plupart des champs qui s'y pretent (sélecteur d'epn ou de salle, sur la création de session, usagers, salle, équipements...)

Application des filtres persistents sur les types d'équipement

Modifications publiées sur le svn (r431) :

La propriété type des périphériques et des logiciels a été renommée respectivement en peri_type et soft_type.
Cette modification permet de les distinguer, ce qui rend notamment possible leur persistence sans confusion.

Ainsi les choix validés sont réappliqués automatiquement en filtre sur les listes, ainsi qu'en choix par défaut sur les formulaires de création.

Mis à jour par Grégory MARIGOT - TEICEE il y a presque 13 ans

  • Statut changé de Résolu à Fermé
Actions

Formats disponibles : Atom PDF