Sitemap

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

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

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_function_profile : table de liaison entre bab_sitemap_functions et bab_sitemap_profiles

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.

Exemples

• On voit ici une représentation du nœud 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.

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

• Actuellement : l'enregistrement des profils en base de données permet d'optimiser le temps d'affichage des sections.
• 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.

Caractéristiques de l'éditeur

• Il sera développé dans un module d'Ovidentia.
• Pouvoir créer plusieurs vues de plan de site.
• Gestion des vues du plan de site : le module stockera les nouvelles vues dans ces 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.
• 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é).
• Lors de l'édition du plan du site, lorsqu'on créé un noeud lié à un noeud existant d'Ovidentia : pouvoir inclure ou pas les noeuds enfants du noeud d'origine.
• Dans un premier temps, l'éditeur s'appuira sur le plan de site complet (contenant la délégation DG_ALL et les autres délégations).

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.

Parralè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éfinies 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 resaisis 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.
• 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 dans l'arbre du module Sitemap ou qui ne contient pas le paramètre smap_node_id, on en sait pas générer de 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 le cadre de la DRE et de la CASQY 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 : rendre possible 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.