Introduction

L'idée de départ est de séparer le canal "Annonces" en deux :

• gestion de la saisie des annonces : le canal annonce

• gestion de la consultation pour diverses sources d'information en format XML : le canal lecture. Voici des exemples de ce qu'il permet de consulter :
  • annonces du portail
  • annonces CMS
  • flux RSS externes
  • site web de formation (concept site d'appui)
  • signets de groupes

Le canal lecture permettra d'afficher des annonces classées par thème eux mêmes situés dans des catégories. On envisage de généraliser ce système à l'affichage de sources d'informations au format XML. Voici la correspondance des termes utilisés (Généralité --> exemple des annonces) :

• Catégorie --> catégorie

• Thème d'annonce --> source XML
• annonce --> item

Spécifications générales

Définitions

Voici les différents objets manipulés par le canal lecture :

• un item : c'est une unité d'information indépendante "autonome" diffusée sous la forme d'un élément XML de format libre.
  exemple : une annonce de l'université, un item RSS

• un flux XML : c'est un ensemble d'items destinés à être affiché par le Canal Lecture par le biais d'une feuille xslt.
  exemple de flux XML utilisés : un flux RSS externe, un flux RSS généré par un CMS d'un site web de formation

• une source XML : c'est l'élément définissant les informations nécessaires à l'obtention et l'affichage d'un flux XML.
  exemple : un thème d'annonce du canal "saisie d'annonce"

• un profil de source : il définit les caractéristiques d'une source (localisation, droits d'accès,...).

• une catégorie : C'est l'élément englobant d'un ensemble de profils de sources.
  exemple : "les annonces de l'université", site d'appui

• un profil de catégorie : il définit les caractéristiques d'une catégorie (localisation, droits d'accès,...).

• un contexte : c'est l'élément englobant d'un ensemble de profils de catégories. Cette notion est utilisée pour l'interface graphique. Un context est lié à un fragment du portail : lors de la configuration du canal dans le portail, on instanciera un canal Lecture à un fragment donné, avec le contexte fourni en paramètre.

• la visibilité d'un élément (une catégorie ou une source) : pour un utilisateur, c'est le droit de visibilité sur l'élément.

• la disponibilité d'un élément : pour les éléments visibles d'un utilisateur, la disponibilité d'un élément est de savoir si l'utilisateur accède à l'affichage de cet élément et pour quelle raison (il y est abonné ou non, de façon obligatoire ou il en est le propriétaire)

Description des objets manipulés

Un item

Un item n'a pas de contrainte de caractéristique. "item" est un nom générique pour un élément XML. Le nom de cet élément XML n'est pas connu à priori. Seule la feuille XSLT (relative à l'item) connait ses spécificités. Si on veut effectuer un zoom sur un item, celui-ci devra contenir un lien vers une URL générant le zoom.

Une source

Elle se caractérise par :

•  un flux XML contenant un ensemble d'items. L'affichage des items se fait grâce à une feuille XSLT conforme au format de l'item. Le repérage de l'item se fait grâce à la définition xpath de l'item.

• les items d'une source sont marqués "lus" ou "non lus"

• une source qui peut être personnelle ou contrôlée :
  • une source personnelle : la source XML provient de la personnalisation du canal lecture par la saisie libre de l'utilisateur.
  • une source contrôlée : la source XML provient de l'ensemble des sources rendues disponibles par l'administrateur du canal. Une source contrôlée a des caractéristiques supplémentaires.

Un profil de Source

Le profil d'une source XML personnelle se définit par :

• la saisie IHM de l'URL du flux XML

• l'adresse générant le flux

• la recherche automatique de :
  • la feuille XSLT
  • l'xpath de l'item
    grâce à un _fichier de mapping DTD-XSLT-path présent au niveau de la config du canal.

Le profil d'une source XML contrôlée est récupéré dans le fichier XML de sa catégorie d'appartenance (cf. catégorie) qui fournit :

• le nom de la source

• l' URL du flux XML : (exemple : url d'un thème d'annonce du portail, url d'un CMS ). Cette URL peut être exprimée à l'aide de variables pour permettre l'utilisation d'URL spécifiques à un utilisateur.

• le _contenu individualisé : oui ou non - Dans la mesure où la requète est authentifié, le flux XML généré est-il spécifique de l'utilisateur ? Cette information va être utile pour l'optimisation des performances.

Les autres caractéristiques y sont indiquées ou prise en compte facultativement (cf. chapitre "origine des données") :

• l'URL de la _feuille XSLTet l'xpath. Si _l'URL de la _feuille XSLT_ et l'xpath de l'item ne sont pas indiqués, on utilise le fichier de mapping DTD-XLST-xpath présent au niveau de la config du canal.
• l'accessibilité : publique ou authentifié - ouverte à tous ou restreinte via une authentification (ex : CAS).
• les ensembles de visibilité : les ensembles désignés ci-dessous constituent l'ensemble des personnes ayant une visibilité sur la source XML :
  • libres : un utilisateur de cet ensemble a le droit de s'abonner et de se désabonner de la source.
  • préabonnés : un utilisateur de cet ensemble est abonné automatiquement à la source et peut se désabonner
  • forcés : un utilisateur de cet ensemble est automatiquement abonné à la source et ne peut pas se désabonner

Le contenu de ces ensembles peut être défini par l'énumération de groupes existants et/ou par l'énoncé d'une règle d'appartenance, exemple :
libres = (groupe Portail "Personnels du CRI")union(les personnes telles que "EmployeeType"="student")

• le timeout : c'est le temps maximum d'attente pour l'obtention d'un flux XML.

L'élément <source-profile> est défini dans la dtd de la category (category.dtd).

Une catégorie

Elle se caractérise par :

• un nom
• une description
• un ensemble de profils de sources XML

Une catégorie peut être personnelle ou contrôlée :

• une _catégorie personnelle : elle est crée par l'utilisateur dans la personnalisation du canal lecture

• une _catégorie contrôlée : elle provient des _catégorie_s rendues disponibles par l'administrateur du canal.

Une catégorie contrôlée a des caractéristiques supplémentaires :

• l'éditabilité : modifiable ou figée : (facultatif : cf. chapitre "origine des données") possibilité pour l'utilisateur d'y ajouter des sources XML (cf. spécifications générales - mise en forme détaillée des besoins)

• les ensembles de visibilité : (facultatif : cf. chapitre "origine des données") les ensembles désignés ci-dessous constituent l'ensemble des personnes ayant une visibilité sur la catégorie :
  • libres : un utilisateur de cet ensemble a le droit de s'abonner et de se désabonner de la _catégorie
  • préabonnés : en plus du droit d'abonnement et de désabonnement, un utilisateur de cet ensemble est automatiquement abonné à la catégorie
  • forcés : un utilisateur de cet ensemble est automatiquement abonné à la catégorie et ne peut pas se désabonner

1. L'élément <Category> est défini dans la dtd de la category (category.dtd)

Un profil de catégorie

1. Pour une catégorie personnelle, il n'y a rien à préciser : le profil est vide.
2. Pour une catégorie contrôlée, on définit son profil au niveau de la config du canal. Le profil d'une catégorie doit contenir :

• le nom de la catégorie
• l'URL du fichier XML de la catégorie (avec possibilité de variables)
• _l'accessibilité _
• le trust-category (faire confiance à la catégorie) qui définit pour les caractéristiques suivantes quelle est la priorité des définitions (cf. chapitre "origine des données") : si trust-catégory est à "vrai", les valeurs définies par la catégorie sont prioritaires mais facultatives, celles définies par le profil sont les valeurs par défaut. Si trust-catégory est à "faux", seules les valeurs définies par le profil sont prises en compte.
• le ttl : temps de rafraichissement d'une donnée distante
• les caractéristiques liées à _trust-category :
  • l'éditabilité
    **les ensembles de visibilité
  • le timeout

1. L'élément <categoryProfile> est défini dans la dtd de la configuration du canal (esup-lecture.dtd)

Un contexte

On définit un context au niveau de la config du canal. Il doit contenir :

• le nom du contexte
• une description du contexte
• un ensemble de références sur des profils de catégories définis dans le même canal.
• l'éditabilité du contexte (création/suppression, abonnement/désabonnement de catégories )

L'accessibilité et les ensembles de visibilité du contexte sont gérés au niveau portail : par le biais du fragment associé au contexte.

L'élément contexte est défini dans la dtd de la configuration du canal (esup-lecture.dtd).

Origine des données : récapitulatif

1. Voici un schéma récapitulatif sur les données manipulées : Unable to render embedded object: File ( Manipulation des données par le canal et le serveur distant # Voici trois tableaux récapitulant la récupération des informations pour les profils de sources XML et de catégories :tab.1 : Origine des données concernant les catégories!tab_categorie.gif!tab. 2 : Origine des données concernant les sources XML!tab_source.gif!tab. 3 : <img class="emoticon" src="/images/icons/emoticons/star_yellow.gif" height=32"16" width=32"16" align="absmiddle" alt="" border="0"/> Priorité sur la définition des paramètres liés à <trust-category>!trust-cat.gif) not found. # Evaluation des ensembles de visibilté : une personne peut apparaître dans deux ensembles de visibilité simultanément. Afin de respecter les priorités, il faut évaluer le contenu des ensembles dans l'ordre suivant : forcés, préabonnés, libres. # La configuration du canal doit contenir les informations suivantes : ** la définition des profils de catégories (contrôlée).

   • la définition des contextes

Le fichier de conguration du canal pourrait être de la forme :

<chanelConfig mappingFile=.../mon_fichier>
  <context ...> ... </context>
  <context ...> ... </context>
  ...
  <categoryProfile ...> ... </categoryProfile>
  <categoryProfile ...> ... </categoryProfile>
  ...
<canal>

Personalisations de l'utilisateur

Tout ce qui est propre à un utilisateur, concernant les catégories et les sources sera enregistré dans le profil de l'utilisateur. Le profil utilisateur contient : * L'état de visualisation des sources et catégories : pliées/selectionnée ou non

• Le marquage d'un item lu ou non lu. Le marquage d'une source ayant des items non lus. Le marquage d'une catégorie ayant de items non lus
• L'ordre de visualisation des sources dans la catégorie, des catégories dans le contexte
• Le mode de visualisation des items
• Le zoom sur la source
• La dimension de la fenêtre de l'arborescence
• Les sources et catégories personnelles, les abonnements aux sources et catégories contrôlées, les importations de sources et catégories controlées

Concernant l'éditabilité des contextes et catégories, le droit d'y créer ses propres catégories ou sources, le droit d'y ajouter des catégories ou sources controllées existantes, rend le système assez complexe. Voici un shéma regroupant toutes les possibilités et les cas que nous avons retenus :

!contexte-cat-sources.gif!Différents cas possibles de personnalisation d'un contexteLégende : * 1 : Deux possibilités : *** action = s'abonner à une catégorie controlée (aucune condition)

• • • action = importer une catégorie controlée (condition : context.edit = managed | all)
      Un contexte peut être vide : il ne peut être relié à aucune catégorie contrôlée. Ainsi cela fournit un contexte entièrement personnalisable pour l'utilisateur du canal.
• 2 : personnalisation
  action = créer ou ajouter (si déjà existante) une catégorie personnelle ( si context.edit = personal | all )

• 3 : s'abonner ou importer une catégorie controlée : cf. 7 ou 8
  Une catégorie contrôlée peut elle n'avoir aucune source contrôlée : peut elle être vide ? Oui ? Pour plus de souplesse (ou robustesse) vis à vis du serveur distant qui fournit les catégorie ?

• 4 : personalisation
  cf.9 (si categorie : edit = all | personal)

• 5 : cas usuel : créer ou ajouter (si déjà existante) une source personnelle dans une catégorie personnelle (pas de condition)
  action = cf. 9

• 6 : importer une source contrôlée (rendue disponible par le canal) (pas de condition) + cf.10
• 7 : Cas usuel
  action = s'abonner à une source contrôlée de la catégorie courante (aucune condition)

• 8 : personnalisation
  action = importer source contrôlée (hors catégorie courante) (si categorie.edit = managed | all )

• 9 : personnalisation
  action = créer ou ajouter (si déjà existante) une source personnelle
  une source personnelle est indépendante d'un contexte. Elle peut existé même si elle n'apparaît dans aucun contexte

• 10 : on choisit de pouvoir importer une source contrôlée qu'elle soit ou non définie (via une catégorie contrôlée du contexte) dans le contexte courant : on rend disponible les sources controlées définies dans des catégories controlées non disponibles dans le contexte courant.
  action = s'abonner à une source contrôlée (rendue disponible par le canal) (si contexte : "edit" = "all")

• 11 : Concernant les sources contrôlées n'appartenant pas à la catégorie contrôlée courante, comme en 10, elles peuvent provenir de différents contextes.
• 12 : Toutes les sources contrôlées rendues disponibles doivent obligatoriement être rattachées à un contexte. On peut imaginer créer un contexte proposant diverses catégories contrôlées, mais qui ne serait pas présenté dans le canal. Ce contexte servirait de "réservoir" à catégories contrôlées pour les personnalisations.

Modification de la caractéristique _edit _: * niveau contexte : Edit =nopersonalmanagedallcomportement du contexteContexte non éditable * abonnement/désabonnement possible de cat. contrôlée du contexte courant

• pas d'ajout/création de catégorie personnelle
• pas d'importation de catégories controlées
  Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
• ajout/création possible de catégorie personnelle
• pas d'importation de catégories controlées
  Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
• pas d'ajout/création de catégorie personnelle
• importation possible de catégories controlées
  Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
• ajout/création possible de catégorie personnelle
• importation possible de catégories controlées

• niveau catégorie controlée:Edit =nopersonalmanagedallcomportement d'une catégorie contrôléeCatégorie non éditable : * abonnement/désabonnement possible de sources contrôlées de la cat. courante
• pas d'ajout/création de sources personnelle
• pas d'importation de sources controlées
  Catégorie éditable :
• abonnement/désabonnement possible de sources contrôlées de la cat. courante
• d'ajout/création possible de sources personnelle
• pas d'importation de sources controlées
  Catégorie éditable :
• abonnement/désabonnement possible de sources contrôlées de la cat. courante
• pas d'ajout/création de sources personnelle
• importation possible de sources controlées
  Catégorie éditable :
• abonnement/désabonnement possible de sources contrôlées de la cat. courante
• ajout/création possible de sources personnelles
• importation possible de sources controlées

• niveau catégorie personnelle : on peut toujours créer/ajouter des sources personnelles et importer des sources controlées : pas de type edit.

Gestion de la dynamique des données

• Rafraichissement des profils de _sources
  XML_ = rafraichir les catégories
  Catégorie contrôllée : à chaque affichage de catégorie, si le ttl de la catégorie est dépassé, les profils de sources XML sont rafraichies.
  Catégorie personnelle : à chaque session utilisateur, tous les profils de sources (personnels et controllés) sont rafraîchis
  (Plus un bouton Refresh pour l'utilisateur ? )

• Rafraichissement d'un flux XML (d'une source XML) = rafraichir les sources
  source contrôllée : à chaque affichage de la source, si le ttl de la source est dépassé, la source est rafraichie.
  source personnelle : à chaque session utilisateur, la source est rafraîchie
  (Plus un bouton Refresh pour l'utilisateur ?)

• Rafraichissement des contexts et profils de catégories : lecture du fichier de configuration du canal. Il est lu à chaque démarrage du canal. Puis lors de l'ouverture de chaque session utilisateur, on vérifie la date de dernière modification de la config et on recharge si besoin.
• la gestion de cache sera précisée plus tard.
• Tout ce qui est commun à plusieurs utilisateurs (catégories et sources controllées) sera enregistré dans un cache global. Les profils utilisateurs auront des pointeurs vers le cache global.

Informations supplémentaires

1. La conception du canal inclura l'internationnalisation # Toutes les URL mises à disposition par le Canal Annonce sont cassifiées. Le canal Lecture sera donc proxy CAS. # La BDD du canal Lecture ne contient aucun contenu de source. # Interface graphique
   A un fragment ou canal sera associé un contexte qui proposera des catégories. Après sélection d'une catégorie, on accède à un ensemble de sources. Par défaut, les sources seront dépliées.
   Le canal lecture pourrait être un canal transversal : sous un fragment donné, on pourrait avoir un contexte dans lequel une seule (ou plusieurs) catégorie est disponible, dans un autre fragment, on aurait aussi le canal lecture seul mais avec un autre contexte proposant d'autres (ou pas) catégories (utilisable pour les souscription forcées à des thèmes d'annonces par exemple).
   L' affichage d'image, le téléchargement de fichiers en lien avec une annonce est géré par le zoom sur un item.
   Pour consulter les informations diffusées par le canal lecture, l'utilisateur dispose de deux modes (on utilisera les 2 modes des portlets) : ** mode view : *** Plier ou non les sources et catégories
   • #** Marquer un item lu ou non lu.
     • Choisir le mode de visualisation des items
     • Zoomer sur la source

• • mode edit : ** gestion de la pagination : ordonner les sources et les catégories** Les sources et catégories personnelles, les abonnements aux sources et catégories contrôlées, les importations de sources et catégories controlées

Interaction du canal avec le système

!global.gif!Fonctionnement du canal lecture en interaction avec le système

(Le schéma ci-dessus n'intègre pas la notion de catégorie pour simplifier la représentation.)

1. Modèle producteur/consommateur
   Le canal de saisie d'annonce et le canal lecture sont dissociés l'un de l'autre et utilisent des bases de données séparées. Ils fonctionnent ensemble sur un modèle de producteur/consommateur.
   Problématique conception "producteur-consommateur" / performances (contexte : producteur = canal Annonce, consommateur = canal lecture) : cf. échange de mails.
2. Pré-requis attendus pour le canal de saisie des annonces
   Le nouveau canal de saisie des annonces devrait être en mesure de mettre à disposition les données suivantes (via des URL): ** des catégorie_s (contenant des profils de sources_) : <category>...</category>
   • le flux XML d'une source (ex : un thème d'annonce avec ses annonces au format RSS ou autre XML)
   • le zoom d'un item

Chaque item fourni dans un flux XML d'une source, devra contenir un lien pointant vers l'URL du zoom de l'item.
Pour pouvoir accéder à la feuille XSLT, le serveur de flux XML devrait fournir l'un des éléments suivants : ** l'URL pointant vers la feuille XSLT (défini dans le profil de la source) et la définition xpath de l'item

• • ou indiquer la DTD du flux XML
    Cette dernière possibilité semble préférable car elle laisse la main au canal Lecture pour le style de l'affichage.

Le canal Annonce ordonne les items d'une source dans le flux XML. Il propose aussi un ordre par défaut pour les sources.
Toutes les URL mises à disposition par le nouveau canal Annonce devraient être cassifiées.
Ergonomie pour le publicateur : la saisie des annonces et la consultation deviennent séparées, il faut malgré tout permettre au rédacteur un moyen de passer aisément de la vue rédacteur à la vue utilisateur : le nouceau canal Annonce pourrait appeler l'URL générant le zoom d'un item.

1. De la même manière, le canal Signet pourrait aussi exporter un ensemble de signets sous forme de _source
   XML_. # Site d'appui
   Dans le contexte du canal lecture, la notion de site d'appui s'implémente par l'abonnement obligatoire à toutes les sources concernées par la formation (ou plusieurs) de l'utilisateur.
   Via les attributs de l'ENT, on pourrait obtenir les étapes APOGEE sur lesquelles l'étudiant est inscrit afin de composer les URL des sites web de(s) la (les) formation(s).
   (cf spécif romuald)

   Spécifications détaillées

Les acteurs

• Utilisateur du canal (utilisateur)
• le portail (portail)
• l'administrateur du canal (admin)

Les cas d'utilisation

Voici l'énumération des cas d'utilisations concernant les catégories : * créer_catégorie

• ajouter_categorie
• supprimer_categorie
• modifier_vue_categorie *** choisir_mode_visu_categorie
  • • deplacer_source

• éditer_catégorie
• abonner_categorie
• importer_categorie
• desabonner_categorie
• enlever_categorie
• afficher_categorie
• deplier_categorie
• replier_categorie
• rafraichir_categorie
• rafraichir_toutes_categories

Voici l'énumération des cas d'utilisations concernant les sources : * creer_source

• ajouter_source
• supprimer_source
• modifier_vue_source *** choisir_mode_visu_source
  • • marquer_item_lu/non_lu
    • zoomer/dezoomer_source

• editer_source
• abonner_source
• importer_source
• desabonner_source
• enlever_source
• afficher_source
• rafraichir_source
• deplier_source
• replier_source
• recherche_xslt

Concernant le contexte :

• afficher_contexte
• editer_contexte (ajout/création/suppression de catégories)
• modifier_vue_contexte ** deplacer_categorie

• rafraichir_contexte
  Autres : * dimensionner_arbre
• authentification
• recuperer_pt_cas
• rafraichir_config_canal

C'est une première énumération des cas d'utilisation apparu nécessaire. Ils seront complétés, modifiés ...lors de la spécification générale.

Concernant les cas d'utilisations dont la mise en oeuvre est manuelle, voici :

• Définir un profil de catégorie contrôlée dans un contexte(<profil-catgory>) par l'édition de la config du canal
• Modifier le profil d'une catégorie contrôlée : édition de la config du canal
• Supprimer un profil de catégorie contrôlée : édition de la config du canal
• Définir un contexte : édition de la config du canal
• Supprimer un contexte : édition de la config du canal
• Ordonner un contexte : édition de la config du canal (l'ordre des catégories est l'ordre de définition dans la config)

  Diagrammes uses-cases

Les diagrammes suivants contiennent la description des uses cases ainsi que les relations entre eux : * actions relatives au contexte : uses cases du fichier docs/specifications/uses-cases/uses-cases-context/index.html

• actions relatives aux catégories : uses cases du fichier docs/specifications/uses-cases/uses-cases-category/index.html
• actions relatives aux sources : uses cases du fichier docs/specifications/uses-cases/uses-cases-source/index.html
• tous les enchainements relatifs à la mise à jour des données : uses cases du fichier docs/specifications/uses-cases/uses-cases-rafraichir/index.html
  Voici quelques précisions : * Action globale : le contexte du canal est en mémoire ainsi que les profils des catégories.
• Action utilisateur : le profil de l'utilisateur vient s'ajouter au contexte du canal et aux profils de catégories.
• Une catégorie contrôllée définie dans un profil utilisateur implique la définition de son profil dans le contexte du canal. Une source contrôllée définie dans un profil utilisateur implique la définition de son profil dans une catégorie contrôllée elle même définie dans le contexte du canal.

Diagrammes de classe

Il faut se référer aux diagrammes UML de conception/développement, présents dans le répertoire _docs/uml/classes du
projet._