Evolution #103

Bibliothèque de supports et ressources pédagogiques

Added by Grégory MARIGOT - TEICEE over 11 years ago. Updated almost 11 years ago.

Status:Fermé Start date:04/07/2011
Priority:Normal Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:ProxyEPN 2.1
Version ProxyEPN:2.0 Beta

Description

Suite à la simplification des thèmes d'ateliers, ceux-ci ne contiennent que des informations générales. La mise à disposition de documents directement dans les thèmes est spprimée.

Cette fonctionnalité doit être remplacée par un gestion documentaire à part :
  • stockage de documents mais aussi enrichissement d'un annuaire de liens internet
  • système de tags pour proposer automatiquement les documents disponibles aux sessions
  • définir les tags sur les thèmes pour simplifier les associations

Un système de tags évolué est à mettre en place pour être à la fois souple (liberté des associations, ajouts de tags) et pratique (tags auto-assignés/proposés, recherche de tags par auto-complétion, etc)


Related issues

related to Evolution #54: Gestion des Thèmes et ateliers Fermé 06/15/2010
related to Evolution #116: Attacher des ressources aux ateliers Fermé 11/14/2011
related to Evolution #122: Script CLI d'import de ressources (fichiers ou liens) Fermé 11/18/2011
related to Evolution #126: Fonctionnalités avancées des tags Fermé 12/07/2011

Associated revisions

Revision 473
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Création d'une gestion documentaire (fichiers et urls)

Revision 484
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Mise en place d'un système de tagging d'objets

Revision 485
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Création d'un nouveau widget de gestion de liste dynamique utilisant jQuery et une saisie avec autocompletion

Revision 487
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Amélioration du nouveau widget myWidgetFormSelectAutocompleter pour accepter la saisie libre de plusieurs valeurs délémitées (suite r485)

Revision 489
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Application du système de 'tags' sur les objets de type WorkshopTheme (thèmes d'ateliers)

Revision 490
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Ajout du module 'tags' pour répondre aux recherches d'autocomplétion (suite r485 et r487)

Revision 491
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #103: Améliorations mineures des pages des modules WorkshopBookmark et WorkshopResource

Revision 500
Added by Grégory MARIGOT - TEICEE almost 11 years ago

FIX #103: Target _blank à l'ouverture des liens du bookmark + non exploitation des champs langue et type

Revision 501
Added by Grégory MARIGOT - TEICEE almost 11 years ago

NEW #103: Ajout du module d'administration des tags

Revision 506
Added by Grégory MARIGOT - TEICEE almost 11 years ago

NEW #103: Intégration du système de tags dans les formulaires des filtres

Revision 507
Added by Grégory MARIGOT - TEICEE almost 11 years ago

NEW #103: Affichage des nuages de tags complets + correction sur les plus populaires

Revision 513
Added by Grégory MARIGOT - TEICEE almost 11 years ago

NEW #103: Nouvelle tâche Symfony pour purger les tags non utilisés

Revision 563
Added by Grégory MARIGOT - TEICEE over 10 years ago

NEW #103: Controles sur l'existence du fichier correspondant à une ressource

Revision 564
Added by Grégory MARIGOT - TEICEE over 10 years ago

NEW #103: Niveau DELETE requis pour modifier l'url ou le fichier d'une ressource

Revision 730
Added by Grégory MARIGOT - TEICEE over 7 years ago

NEW #78, #103 : mise en place de permissions pour l'administration des tags

History

Updated by Grégory MARIGOT - TEICEE over 11 years ago

  • Target version set to ProxyEPN 2.1

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

  • Status changed from Nouveau to In Progress
  • Assignee set to Grégory MARIGOT - TEICEE
  • % Done changed from 0 to 20

Modifications publiées sur le svn (r473) :

Gestion de ressources documentaires en base de données

Deux tables relativement similaires sont ajoutées dans la base pour enregistrer respectivement les documents et les liens web, avec quelques informations les permettant de les qualifier :

workshop_bookmark : liens web

  • id : identifiant unique en auto-incrément
  • legend : titre associé au lien (obligatoire)
  • description : informations détaillées libres
  • url : adresse internet du lien
  • linktype : type de ressource pointée (à définir)
  • language : langue de la ressource pointée
  • restriction : champs d'accès à cette ressource (à définir)
  • structure_id : EPN ayant fourni le lien
  • nb_hits : compteur de clic sur le lien

workshop_resource : documents uploadés

  • id : identifiant unique en auto-incrément
  • legend : titre associé au fichier (obligatoire)
  • description : informations détaillées libres
  • filepath : nom interne du fichier uploadé
  • filename : nom d'origine du fichier uploadé
  • filesize : taille du fichier uploadé
  • filetype : type MIME du fichier uploadé
  • language : langue de la ressource uploadée
  • restriction : champs d'accès à cette ressource (à définir)
  • structure_id : EPN ayant fourni le fichier
  • nb_hits : compteur de clic sur le fichier

Notion de propriété sur les ressources

Les deux tables disposent aussi des champs standards du module signable :
  • created_at : date de création de la ressource
  • created_by : utilisateur ayant créé la fiche
  • updated_at : date de dernière modification
  • updated_by : utilisateur ayant effectué la modification

Ces champs permettent un suivi automatique mais ne sont pas utilisés pour définir un propriétaire aux ressources : pour cette notion les ressources sont rattachées à un EPN.

Dans un premier temps l'objectif est de fournir une base documentaire commune et partagée entre tous les EPN. C'est donc au nom d'un EPN que les ressources sont publiées, cette indication reste essentiellement informative (permettant aussi de filtrer pour les rechercher).

Dans un second temps il sera envisageable d'appliquer des restrictions d'accès, en utilisant le champs restriction, afin de rendre par exemple des ressources publiques ou privées (internes à l'EPN / partagées au GEPN / ouverte à tous ?).

Stockage et accès aux ressources

Pour les liens, les URL sont directement stockées dans la table de la BdD. Par contre pour les documents, les fichiers uploadés sont enregistrés sur le système de fichier dans le sous-dossier web/uploads/resources/

Un nom de fichier aléatoire et unique est généré automatiquement au moment de l'upload d'un document, permettant leur enregistrement dans le dossier sans risque de collision. Divers documents ayant le même nom d'origine peuvent donc coexister sans problème.

Les informations telles que le nom d'origine, la taille et le type MIME des fichiers sont également déterminées automatiquement.

Enfin l'accès aux ressources est rendu possible au travers d'une action du module MVC. Celle-ci permet d'appliquer des controles de permission, de transmettre la ressource avec ses informations d'origine (nom, type) ainsi que de tenir à jour un compteur d'accès.

Modules MVC sur les ressources

Les modules workshop_resource et workshop_bookmark permettent d'effectuer les actions de base pour la gestion des documents et liens web :
  • Liste des ressources (avec tris et filtres)
  • Formulaires de création/édition et suppression
  • Fiche détaillée et ouverture de la ressource

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

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.

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

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.

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

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

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

  • Status changed from In Progress to Résolu
  • % Done changed from 20 to 100
L'application dispose à présent d'une gestion documentaire opérationelle :
  • des fichiers comme des liens web peuvent être enregistrés pour l'alimenter, avec divers champs descriptifs
  • un système de tags est applicable sur toutes les ressources, permettant d'affiner leur catégorisation
  • la recherche de ressources peut s'effectuer en utilisant plusieurs filtres, dont l'usage des tags
  • les ressources peuvent être protégées et sont accessibles via une action disposant entre autre d'un compteur

Une seconde partie consistera à exploiter cette base documentaire directement sur les fiches des ateliers : une sélection de ressources pourra être définie (usage des tags pour les choisir) et attachée à ces sessions.

Ceci fait l'objet d'un autre ticket (cf #116). Celui-ci peut être clos.

Updated by Grégory MARIGOT - TEICEE almost 11 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF