Sitemap : Différence entre versions

De OviWiki
Aller à : navigation, rechercher
(Sitemap dans la base de données)
(Sitemap dans la base de données)
Ligne 30 : Ligne 30 :
 
bab_sitemap_function_labels : enregistre les libellés de chaque fonction dans toutes les langues disponibles
 
bab_sitemap_function_labels : enregistre les libellés de chaque fonction dans toutes les langues disponibles
  
bab_sitemap_function_profile : table de liaison entre functions et profils
+
bab_sitemap_function_profile : table de liaison entre bab_sitemap_functions et bab_sitemap_profiles
  
bab_sitemap_profiles : enregistre tous les profils différents des utilisateurs. Un profil correspond à une vue de l'arbre respectant les droits d'accès. Un profil est un ensemble de nœuds de l'arbre disponible pour 1 ou plusieurs utilisateurs. Si plusieurs utilisateurs ont le même arbre, ils ont le même profil.
+
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==
 
==Exemples==

Version du 25 mai 2009 à 13:42

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 :


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


Intérêt du plan du site

  • Actuellement : l'enregistrement des profils en base de données permet de gagner en performances à l'affichage des sections d'Ovidentia.
  • Le plan du site est accessible par OVML afin de récupérer des informations comme les entrées dans les sections Administration et Utilisateur : container OCSitemapEntries.
  • Les entrées du plan du site soint définies et dynamiques (un nouvel objet se créé dans Ovidentia : un noeud est immédiatement créé) à la différence du module Sitemap où tous les nœuds sont créés manuellement.

Evolutions proches

Objectif : pouvoir personnaliser le plan du site afin de définir une nouvelle navigation dans le portail.

  • Création d'un éditeur permettant de créer des vues différentes de l'arbre du plan du site. L'éditeur est développé dans un module d'Ovidentia, le module stocke dans ces tables le nouvel arbre et fournit un arbre d'objet bab_siteMap (exploitable dans les API).

Possibilité du module : réordonner les entrées, supprimer des entrées, modifier les libellés (gestion multi-langues ?).

Evolution du module Sitemap ou autre module ? : peut-on mélanger des nœuds de type URL du module Sitemap avec des nœuds du plan du site d'Ovidentia ?

  • Rendre exploitable ces vues dans l'OVML : évolution du container OCSitemapEntries.
  • L'API du noyau doit permettre à n'import quel module de créer son plan du site personnalisé.
  • Les modules doivent pouvoir fournir leurs entrées dans Sitemap : voir bab_onSiteMapItems($event)
  • Gestion des délégations : actuellement les délégations ne sont pas gérées correctement dans le plan du site :

Lorsqu'on récupère les entrées, il faudrait pouvoir filtrer par la délégation courante.

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.


Le module Sitemap

  • 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 ().

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 :

On utilise pas le chemin de fer d'Ovidentia pour les articles

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. Isofonctionnalité avec le module Sitemap (noeud externe au site (url)).

  • Isofonctionnalité avec le module Sitemap :
  • Gérer les balises pour le référencement : title, métas pour chaque noeud du plan du site. Aujourd'hui les balises sont statiques et présentes dans le template config.html.
  • Générer le fichier sitemap.xml utilisé par les moteurs de recherches.
  • Pouvoir réécrire les urls (aide au référencement).
  • Gestion du chemin de fer automatiquement (équivalent smap_node_id).

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'abre 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.

  • Gestion de nœuds externes au site dans l'arbre du plan du site (urls).
  • 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 : plus de sections, navigation sur plusieurs niveaux.

Problèmes à gérer

  • 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 ?
  • Comment utiliser un plan du site créé dans un module autre que Sitemap par OVML ?