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.