ProxyEPN

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.

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.