ProxyEPN

Modifications publiées sur le svn (r484) :

Mise en place d'un système de tags¶

L'application doit disposer d'un système de tags général, permettant d'en associer à n'importe quel type d'objets. Pour celà les tags reposent sur deux nouvelles tables :

Tag : liste des tags existants¶

• id : identifiant unique en auto-incrément
• key : forme canonisée du tag
• label : libellé d'origine du tag

Cette table permet de stocker tous les tags connus, sans se préoccuper de leur usage. Elle est très utile pour obtenir la liste exhaustive des tags, notament pour proposer les tags déjà existants lorqu'on souhaite tagger un objet.

La présence de l'identifiant simplifie l'usage du tag dans le temps puisqu'il est fixe, contrairement au libellé (et donc aussi la forme canonisée) qui peuvent être modifiées. En créant les associations sur cet id on assure facilement leur pérenité tout en permettant l'édition à posteriori des noms.

Lorsqu'un tag est créé, seul son libellé est nécessaire, la forme canonisée en est déduite. Cette dernière est utilisée en interne pour éviter les doublons et faciliter la reconnaissance et les recherches approchées (ex: les termes "Là bas", "LA-BAS", "LàBas" feront tous références au tag canonisé "labas").

Tagging : liste des associations entre tag et objet¶

• id : identifiant unique en auto-incrément
• tag_id : référence du tag utilisé
• obj_id : référence de l'objet taggé
• model : nom du modèle de l'objet taggé

Puisque les tags sont prévus pour être utilisés sur tout type d'objet, il est nécessaire que l'objet cible soit défini par 2 champs : son modèle (nom de la classe) et sa référence (identifiant numérique obligatoirement).

Par conséquent cette table de lien ne peut définir en dur les contraintes classiques de clés étrangères, puisque la table des objets n'est pas unique.

Classes utilitaires du système de tags¶

Les classes de base sont générées par Propel (Tag, TagPeer, Tagging et TaggingPeer). Elles sont ensuite enrichies de plusieurs méthodes spécifiques pour répondre aux besoins de manipulations :

• Ajout/Suppression d'un tag sur un objet (association dans la table tagging + création dans la table tag s'il n'existait pas encore)
• Liste des tags associés à un objet
• Recherche de tags selon divers critères
• Liste des tags par popularité (comptage de leurs occurences dans la table tagging)
• Analyse et traitement des tags saisis par l'utilisateur (découpage, canonisation)

Définition d'un behavior pour les objets taggables¶

Lorsqu'on décide qu'un type d'objet doit pouvoir être taggé, il est utile que la classe de ces objets soit enrichie de quelques fonctions spécifiques. C'est ce qui est offert par MyPropelBehaviorTaggable.

Ce behavior Propel est à spécifier sur les classes souhaitées dans le schema.xml, afin que la génération des classes de base l'utilise pour ajouter un ensemble de méthodes communes.

Ces méthodes sont généralement des appels aux méthodes définies dans les classes statiques TagPeer et TaggingPeer. Mais elles facilitent l'exploitation des tags en étant appelées directement depuis l'objet concerné.

A noter que le behavior définit également les méthodes "postSave()" et "postDelete()" afin d'enregistrer/supprimer automatiquement les tags associés.

Modifications publiées sur le svn (r485, r487 et r490) :

Nouveau widget de liste dynamique avec autocomplétion¶

L'usage de tags dans l'interface nécessitait un widget d'un nouveau genre : capable de présenter une liste d'élément, d'en retirer ou d'en ajouter, l'ajout se faisant par un champs texte libre assisté d'une recherche par autocomplétion.

Création d'un plugin jQuery : DynList¶

Ce plugin permet de transformer une liste multiple classique (balise select) en une liste dynamique : les éléments sélectionnés sont présentés dans une liste HTML (ul/li), avec pour chacun une icone permettant de les retirer. De plus un bouton permet d'ajouter de nouveaux éléments dans cette liste via un champs texte.

Toutes ces opérations sont dynamiques côté client, sans aucune intervention du serveur (pas d'AJAX). Ceci signifie que les ajouts/suppressions ne sont effectués qu'au niveau du formulaire et que ce n'est qu'au moment de sa validation que la liste sera traitée par le serveur.

Le plugin jQuery peut être appliqué sur un select existant (auquel cas il le masque pour le remplacer) ou sur une liste transmise (il se charge alors de créer le select masqué). De nombreuses options sont disponibles pour le paramétrer et l'adapter à ses besoins.

Le champs textuel de saisie peut au choix rester affiché ou être masqué : dans ce cas seul un bouton est présent pour le faire apparaitre et il est remasquer après validation du nouvel élément.

Le nouveau widget myWidgetFormSelectAutocompleter¶

Ce widget Symfony fait partie de la famille des sélecteurs de liste, mais il repose essentiellement sur le plugin jQuery défini précédement. Ainsi son élément principal sera une balise select que le javascript masquera.

Mais ce widget est hybride puisqu'il dispose également d'un champs texte pour la saisie de nouveaux éléments qui repose sur le plugin jQuery d'autocomplétion (via AJAX). La définition du widget se charge ainsi de marier ces deux plugins jQuery.

Chacun des plugins dispose de nombreuses options que le widget se charge d'initialiser avec les valeurs appropriées : définies en dur ou valeurs par défaut paramétrables. Ainsi le widget dispose de ses propres options pour le paramétrer et modifier tous les paramètres pouvant être utiles à son fonctionnement et à sa présentation.

Un nouveau validateur sfValidatorChoiceFree¶

Si le widget précédent hérite de la classe parente sfWidgetFormSelect, son mode de fonctionnement amène une distinction importante : la liste des choix possibles est libre et illimitée. Ainsi contrairement aux autres widgets de liste habituels, il n'est pas possible de fournir cette liste.

Le widget doit donc se contenter d'être créer avec la liste des choix existants (tous considérés comme étant sélectionnés). Son fonctionnement permet l'ajout de nouveaux éléments quelconque (saisie libre du champs texte) qui sont automatiquement sélectionnés.

Par conséquent le validateur employé doit être particulièrement souple : tous les éléments sont valables. Ainsi la classe sfValidatorChoiceFree n'imposera pas que les valeurs transmises soient présentes dans une liste de choix possibles particuliers.

Gestion de l'auto-complétion¶

Un module 'tags' est ajouté avec une action permettant de répondre aux demandes AJAX d'autocomplétion.

Module d'administration des tags existants¶

Modifications publiées sur le svn (r501) :

Jusqu'à présent le module 'tags' n'était utilisé que pour effectuer les recherches de l'autocomplétion du widget. Mais il peut aussi être utile de disposer d'une interface d'administration générale sur les tags. Ainsi les actions classiques y sont ajoutées : lister / créer / éditer / supprimer.

La liste des tags est exhaustive, quelque soit leur usage. Mais des filtres permettent de n'afficher que les tags utilisés sur tel ou tel modèle d'objets. Ou tout simplement : ne lister que les tags utilisés ou non utilisés.

Avec le temps, la liste des tags s'enrichit et des opérations de maintenance peuvent être pratique pour la garder propre : renommage de certains libellé, suppression de tags peu pertinents, fusion de tags faisant doublon...

En éditant un tag on peut essentiellement modifier son libellé. Pour information on dispose de la liste de tous les objets taggés avec. En supprimant un tag, toutes ses associations sur des objets sont automatiquement supprimées. Enfin il est également possible de retagger tous les objets associés avec un autre tag existant (utile pour fusionner avant de supprimer ce tag).

Une action supplémentaire permet également en un clic de supprimer tous les tags existants qui ne sont plus utilisés par aucun objet (afin de nettoyer la table et qu'ils ne soient plus proposés par l'autocomplétion).

Utilisation du widget dans les formulaires des filtres¶

Modifications publiées sur le svn (r506) :

Pour les objets utilisant des tags, il est pertinent que la page présentant leur liste puisse les exploiter au mieux. Un filtre supplémentaire doit alors permettre la saisie de tags et afficher la liste de ceux actuellement sélectionnés.

Si plusieurs tags sont saisis, le filtre appliqué correspond à un "ET" sur les deux critères. Cumuler des tags permet donc d'affiner la recherche en ne listant que les objets les contenant tous.

Le widget a dû subir quelques modifications et améliorations pour le rendre plus souple et facilement intégrable dans ce type de formulaire.

Présentation des nuages de tags¶

Modifications publiées sur le svn (r507) :

Le système de tags contient également un helper Symfony avec quelques fonctions utiles à leur présentation, essentiellement pour l'affichage de listes de tags (tags d'un objet ou nuage de tags existants).

Les nuages ont la particularité de modifier la taille de police de chaque libellé de tag en fonction de leur usage (nombre d'occurences des associations tag-objet). Il devient possible d'afficher des nuages en précisant le nombre correspondant.

Sur l'application, les pages listant des objets taggables proposent la liste des tags les plus populaires dans la colonne de gauche (après le menu). L'espace y est limité mais reste adapté pour une liste de tags courte (les 25 plus utilisés par exemple).
Néanmoins il est toujours interessant de pouvoir visualiser la liste complète des tags liés à un modèle d'objet.

Pour celà une nouvelle route est définie : ":module/tags". Elle permet de définir une action commune à divers modules, proposant d'afficher le nuage de tags complet correspondant.

Nouvelle tâche Symfony : proxyepnTagsPurgeTask¶

Modifications publiées sur le svn (r513) :

Cette tâche permet de lancer en ligne de commande une suppression des tags inutilisés. Ainsi cette procédure peut être automatisée régulièrement en tâche Cron si on juge qu'un tag sans association n'a pas à polluer la liste des tags disponibles.

Elle se lance avec la commande : ./symfony proxyepn:tags-purge