Sitemap

Un article de OviWiki.


Résumé des développements pour le plan du site (Sitemap)
du noyau Ovidentia



Sommaire

Description

  • Un plan du site est une représentation de l'architecture du site, il liste les ressources proposées aux utilisateurs. Dans Ovidentia le plan du site est représenté par un arbre. Une ressource (ou nœud de l'arbre) peut être un objet d'Ovidentia (thème d'articles, faq, site...), la section Utilisateur, une délégation...
  • Tous les objets d’Ovidentia ne sont pas forcément présents dans le plan du site.

Pourquoi un plan du site ?

  1. Avec la gestion de profils utilisateurs, il est possible d'enregistrer un plan du site par profil en base de données. L'enregistrement sera exploité à chaque page sans avoir à recalculer tous les droits d'accès aux objets. On aura donc un cache qui optimiserait le temps d'affichage des pages (ex : les liens en section Utilisateur n'auraient pas besoin d'être recalculés tout le temps).
  2. Définir un chemin de fer (aussi nommé rail, fil d'Ariane, breadcrumb) afin de localiser l'utilisateur sur le site. Actuellement, seule la fonction Articles propose un chemin de fer.
  3. Faciliter la navigation. L'arbre du plan du site sera réutilisable par d'autres applications qui pourront proposer des alternatives aux sections Utilisateur et Administration : menus déroulants, navigation horizontale...
  4. Personnaliser le plan du site. Des éditeurs permettront la personnalisation du plan du site : suppression de noeuds, renommages de noeuds...


Exemple de navigation aérée sans sections
Exemple de navigation aérée sans sections

Sitemap dans la base de données

  • Actuellement l'arbre est sauvegardé dans la base de données dans les tables préfixées par sitemap :

bab_sitemap : enregistre l'arbre du plan du site

bab_sitemap_functions : enregistre tous les nœuds disponibles par Ovidentia et ses modules : noeuds conteneurs (ex : section Utilisateur) et nœuds enfants (ex : lien options)

bab_sitemap_function_labels : enregistre les libellés de chaque fonction dans toutes les langues disponibles

bab_sitemap_profiles : enregistre tous les profils des utilisateurs. Un profil correspond à une vue spécifique de l'arbre pour un ou plusieurs utilisateurs : la vue respecte donc les droits d'accès sur les objets d'Ovidentia. Si plusieurs utilisateurs ont la même vue, ils ont le même profil.

bab_sitemap_function_profile : table de liaison entre bab_sitemap_functions et bab_sitemap_profiles

Exemples

  • On voit ici une représentation du nœud AdminSection du plan du site :


Noeud AdminSection du plan du site
  • Ici, une représentation du nœud Articles dans le plan du site :

A gauche : arborescence des catégories et thèmes d'articles vue par l'administrateur du site.
A droite : représentation par le plan du site.

Noeud Articles dans l'administration Noeud Articles du plan du site

API sur Sitemap

La classe bab_siteMap gère le plan du site :

La méthode get() permet de récupérer l'arbre (objets bab_Node)

La méthode build() construit l'arbre en base

La méthode clear() réinitialise l'arbre

La méthode getUrlById() et getNameById() permet d'avoir des informations sur un nœud

La classe bab_siteMapItem gère un nœud du plan du site


Sitemap aujourd'hui

  • L'API permet de fournir l'arbre entier du plan de site selon un objet bien défini.
  • Actuellement : l'enregistrement des profils en base de données permet d'optimiser le temps d'affichage des sections Administration et Utilisateur.
  • Les nœuds enregistrés dans le plan de site sont de type conteneurs ou enfants. Dans la capture au-dessus, les nœuds Sites et Ovidentia sont des nœuds de type conteneurs.
  • Tous les nœuds peuvent avoir un libellé, un identifiant unique, une description, une url, un type (conteneur ou enfant), un code javascript à exécuter sur l'événement onclick du lien et une icône.
  • Seuls ces objets sont gérés dans le plan du site : sites, faqs, articles, catégories d'articles, thèmes d'articles, délégations
  • La création du plan du site s'effectue par des profils. Ces profils sont enregistrés et modifiés à des évènements particuliers : enregistrement des ACL, accès à un objet.
  • Le plan du site est accessible par OVML : container OCSitemapEntries. Il est possible de lister les noeuds du plan du site comme les entrées de la section Administration ou Utilisateur.

Liste des variables OVML disponibles :

    • OVSitemapEntryId : Identifiant unique de l'entrée (chaîne de caractères)
    • OVSitemapEntryUrl : Adresse Web (url) de l'entrée
    • OVSitemapEntryText : Nom de l'entrée
    • OVSitemapEntryDescription : Description de l'entrée
    • OVSitemapEntryOnclick : Code javascript à exécuter sur l'entrée (événement onclick sur le lien)
    • OVSitemapEntryFolder : Vaut 1 si l'entrée est un répertoire (conteneur d'entrées) sinon 0
  • Les principaux noeuds conteneurs ont été définis. Le plan du site est dynamique : il est modifié à la volée dès l'instant qu'a lieu une modification sur un objet d'Ovidentia.

Evolutions proches

Éditeur de plan de site

Réalisation d'un éditeur de plan de site : permettre la création de nouvelles vues du plan du site. L'objectif étant la personnalisation du plan du site en vue de définir une nouvelle navigation sur le site. Les skins pourraient donc bénéficier de l'arbre généré.

Caractéristiques de l'éditeur

  • Il sera développé dans un module d'Ovidentia.
  • Pouvoir créer plusieurs vues de plan de site.
  • Au moment de la création d'un nouveau plan de site, on choisit si on veut partir d'un arbre vide ou d'un arbre complet (contenant tous les noeuds d'Ovidentia).
  • Gestion des vues du plan de site : le module stockera les nouvelles vues dans ses tables de données. Le module s'enregistrera sur un évènement afin de fournir les vues au noyau Ovidentia : la vue sera soumise sous la forme d'un objet bab_siteMap. L'événement sera utilisé par la fonction de l'API qui listera tous les plans de site disponibles.
  • A la création d'un nœud les options suivants apparaitront : nœud lié à un nœud existant du plan de site d'origine ou pas : les noeuds non liés permettent la création de catégories supplémentaires (nœuds conteneurs) dans l'arbre ou la création de liens externes au portail.
  • Lorsqu'on créé un noeud lié à un noeud existant du plan de site d'origine : pouvoir inclure ou pas les noeuds enfants du noeud d'origine.
  • Possibilité de réordonner les entrées, supprimer des entrées, modifier les libellés, cacher des entrées.
  • Gestion multi-langues (le stockage des informations multi-langues sera peut-être effectué par un autre module dédié).
  • Dans un premier temps, l'éditeur s'appuiera sur le plan de site complet (toutes délégations confondues) (contenant la délégation DG_ALL et les autres délégations).
  • Pour simplifier l'ajout d'un nœud dans le plan de site modifié, qui s'appuie sur un nœud existant, une case de recherche effectuera une recherche dans le plan de site d'origine et retournera les résultats.
  • Une application qui récupère un objet plan de site peut en faire n'importe quoi. Actuellement le plan de site est utilisé par le noyau pour afficher les sections Administration et Utilisateur. Si un plan de site modifié remplace le plan de site par défaut, le noyau demandera par API les enfants du nœud AdminSection et du nœud UserSection du plan de site modifié : si les nœuds sont renommés ou quelques uns supprimés : les sections seront générées.

Si le nœud AdminSection est caché, la section n'apparaîtrera pas dans le skin qui utiliserait le plan de site.

  • Comment gérer un lien qui apparaît dans la section Utilisateur après la création d'un nouveau plan de site personnalisé ? : le lien doit-il apparaître ?

Il semble qu'une option supplémentaire doit être ajoutée : cacher tous les nouveaux liens.

  • Implication d'un plan de site avec les droits d'accès : si un article est caché du plan de site : un menu qui utiliserait ce plan n'affichera pas le lien vers l'article. Attention : ceci n'indique pas que l'utilisateur n'a plus du tout accès à l'article sur le portail.
  • Pouvoir surcharger les droits d'accès d'un nœud.

Interface

  • Gestion de plusieurs plans de site
  • Page principale : affichage de l'arbre en cours. Bouton de création d'un noeud.
  • Création d'un noeud : lié ou pas à un noeud existant d'Ovidentia.

Si lié à un noeud existant d'Ovidentia, une case de recherche permet de rechercher le noeud désiré dans le plan du site d'origine.

Autres évolutions

  • Association d'une icône à chaque nœud (en cours)
  • L'API ne peut pas fournir une partie du plan du site. Actuellement, tout le plan de site est retourné.
  • Les délégations sont mal gérées avec le plan de site :

Fonctionnement actuel des délégations :
Lorsqu'un utilisateur fait partie de plusieurs délégations, il lui est impossible de passer d'une délégation à une autre (on parle ici d'un utilisateur non administrateur) : tous les éléments dont l'utilisateur a droit sont affichés en même temps, toutes délégations confondues. La section utilisateur est gérée de cette manière : toutes délégations confondues.
Problème : la section Administration n fonctionne pas de la même manière car un administrateur délégué ne voit pas les liens toutes délégations confondues.
Solution :
Les modifications à apporter dans le noyau sont décrites dans l'article : Délégations pour qu'il soit possible d'avoir un sélecteur de délégation qui fonctionne a la fois pour l'administration et pour l'utilisation.

  • Gérer plus d'objets dans le plan du site : fichiers, répertoires, notes…

Tous les objets doivent être associés à un identifiant unique.

  • La création et la modification des profils de plan de site doivent s'effectuer à chaque création/modification/suppression d'objets. Ceci implique que l'API plan de site doit être améliorée et que chaque objet doit utiliser cette API pour référer des opérations sur l'objet (héritages de classes ?).
  • Gérer un chemin de fer pour tous les objets. Commet gérer l'objet qui apparaît dans plusieurs nœuds du même plan du site ?
  • Pour l'éditeur, l'API devra grandir : un module doit pouvoir communiquer avec le noyau Ovidentia afin de récupérer le plan de site en cours, récupérer les enfants d'un nœud, rendre par défaut un plan de site modifié…

Mais un module doit pouvoir aussi s'enregistrer sur des événements afin de savoir par exemple qu'un nouveau lien existe dans la section Utilisateur.

Parallèle avec le module Sitemap existant (module privé)

Le module Sitemap est utilisé dans tous les sites et skins d'Ovidentia. Il permet de définir une arborescence de navigation en opposé à l'arborescence de publication définie par l'administrateur du site (Conteneurs catégories et thèmes d'articles).

Fonctionnement

Chaque noeud peut être de type nul, url, catégorie, thème ou article.

L'arborescence est entièrement exploitable

Problèmes récurrents à l'utilisation du module

Le chemin de fer d'Ovidentia, présent dans les articles, est caché. Le chemin de fer remplaçant s'appuie sur l'arborescence du module Sitemap.

Générer le chemin de fer demande le passage du paramètre smap_node_id dans les urls ou la vérification des paramètres de l'url pour connaître la page en cours

Tous les noeuds vers des objets d'Ovidentia doivent être ressaisis manuellement

Avantages

Il est possible de définir des valeurs pour chaque noeud qui seront utilisées pour le référencement du site par les moteurs de recherche : ces valeurs sont appliquées aux balises title et méta

On a une solution aux faiblesses du noyau d'Ovidentia

Evolutions du module Sitemap

Pouvoir associer une image à un noeud

Pouvoir associer une couleur à un noeud

Avoir plus de types de noeuds : faq, applications forms...

Evolutions lointaines

Objectif : maîtriser la navigation dans Ovidentia par le plan du site.

  • Possibilité de mélanger aux noeuds d'Ovidentia des noeuds de type URL EXTERNE.
  • Possibilité d'appliquer des droits d'accès sur un noeud du plan du site.
  • Gérer les balises pour le référencement pour chaque noeud : title, balises métas...
  • Générer le fichier sitemap.xml pour les utilisateurs anonymes : le fichier XML est utilisé par les moteurs de recherche.
  • Pouvoir réécrire les urls ( URL REWRITING ).
  • Affichage automatique du chemin de fer en s'appuyant sur le plan du site.

Explication :

Actuellement le chemin de fer s'appuie sur le module Sitemap. Pour qu'un script OVML génère le chemin de fer, il est nécessaire de vérifier si la page en cours d'affichage par l'utilisateur provient de l'arbre du module Sitemap ou pas. Pour cela, tous les liens générés par le module Sitemap ajoute le paramètre smap_node_id. Ainsi le script qui génère le chemin de fer vérifie l'existence du paramètre smap_node_id dans l'url et si elle existe il interroge le module Sitemap pour connaître l'emplacement du noeud dans l'arbre et donc le chemin de fer.

Problème : lorsqu'on se trouve sur une page qui n'est pas connue dans l'arbre du module Sitemap ou dont l'url ne contient pas le paramètre smap_node_id, on ne sait pas générer le chemin de fer.

Solution : Ovidentia peut créer une variable globale qui aurait pour valeur l'identifiant unique du nœud correspondant à la page en cours affichée (thème, article, contribution de forum...). Ceci permettrait à Ovidentia ou à un script OVML de générer le chemin de fer à partir de l'identifiant unique du nœud dans le plan du site d'Ovidentia.

  • Définir des identifiants uniques sur les noeuds de l'arbre pour chaque objet d'Ovidentia (Exemple pour un article : bab_article_delegation0_129).
  • API pour l'OVML : récupération du chemin de fer, informations sur un noeud, pouvoir filtrer les entrées du plan du site sur une délégation. Ce développement peut éviter tous les scripts OVML développés dans certains sites afin de générer des menus filtrés par la délégation en cours. Rappel : par défaut si on appartient à plusieurs délégations, tous les objets de la délégation apparaissent en même temps sur l'interface d'Ovidentia (sections...).
  • Adaptation des skins d'Ovidentia avec les nouveaux arbres de plan de site : pertes des sections, navigation sur plusieurs niveaux...

Questions en l'air

  • Un noeud à identifiant unique peut se retrouver à plusieurs endroits dans l'arbre : comment gérer le chemin de fer ?
  • Comment gérer une section Utilisateur présente dans 2 délégations par OVML ?
  • L'API d'Ovidentia ne sait pas retourner une partie du plan du site.
  • Gestion des délégations dans le plan du site : permettre de récupérer, pour un utilisateur, une vue par délégation dont il fait partie.
  • Régulariser les filtres sur les délégations par variables globales.
  • L'API doit pouvoir retourner une vue du plan du site sans tenir compte des droits d'accès afin que l'administrateur qui édite un plan du site puisse préparer un plan pour tous les utilisateurs.
  • La section Utilisateur peut apparaître dans 2 délégations. Dans ce cas, son identifiant unique de nœud prendrait en compte l'identifiant de la délégation ?