Nous allons voir ici l'architecture du portail en détail en insistant sur les principes de fonctionnement. La complexité des fichiers de paramétrage de SharePoint (qui soit dit en passant fait bien plus de choses que mon portail) a été une source d'inspiration pour concevoir l'architecture de cette application. Je vais donc vous expliquer comment les données sont hiérarchisées avec l'implication sur l'interface graphique, le modèle de paramétrage des différents espaces pour finir sur les multiples capacités de personnalisation du portail.

1.Hiérarchie des données

1.1. Un SiteMap issue de la base de données

J'ai décidé de m'appuyer sur un SiteMap pour la hierarchisation de mes informations, stocké en base. Un SqlSiteMapProvider a été utilisé pour obtenir les informations qui s'étalent sur 3 niveaux :

• Niveau 0, la home page
• Niveau 1, les espaces principaux
• Niveau 2, les sous espaces

Chaque élément de publication sera alors disposé dans un élément de niveau 2 obligatoirement. Les ID des espaces sont des entiers classés, c'est à dire qu'une requête en classant par ID vous donne automatiquement l'arborescence sans avoir à faire de la récursivité, gourmande en ressources. Le défaut est l'impossibilité de déplacer le moindre élément, contrainte que j'ai accepté dans ce développement.

L'ID du SiteMap ne sert qu'a simplifier le rendu. Chaque espace et sous espace dispose d'un raccourci. Ici le nom du raccourci est ACTIVITE.

L'interface graphique, au niveau de la navigation est alors générée automatiquement. Les zones à gauche et à droite de la liste des espaces de niveau 2 sont disposés dans un fichier de paramétrage. Il s'agit d'un fichier XML qui décrit les données à afficher à gauche et à droite en fonction du raccourci d'un espace de niveau 1.

1.2. Le pilotage de la zone de navigation

C'est au niveau de la classe qui dévire de MasterPage que le calcul de la localisation dans l'application se fait. En fonction de l'Url, l'application saura si elle se trouve sur la HOMEPAGE ou dans un espace de niveau 1 ou 2 connu. En fonction de l'espace de niveau 0 ou 1, l'application affichera automatiquement la bonne zone de navigation par défaut. Une variable de contexte est disponible également pour qu'au niveau du code on sache exactement dans quelle zone on se trouve. Cette donnée est vitale car elle permet d'afficher les bonnes données au bon endroit.

1.3.Le raccourci en cours, clé de la variation du contenu

C'est une variable d'environnement, disponible dans les classes dérivées de MasterPage, Page et UserControl qui permet coté serveur de savoir dans quelle espace on se trouve. La hiérarchie est ici respectée. Dans un espace de niveau 2, le plus bas, on ne disposera que des éléments de contenu de ce niveau. Par contre, dans un espace de niveau 1, on restitue l'ensemble des données de niveau 2 qui lui sont dépendants. Au niveau 0, sur la home page, c'est l'ensemble des données de niveau 2 qui est restitué.

1.4. La hierarchie conservée dans le contenu

Au sein de chaque espace, la hiérarchie du contenu est conservée au niveau des nuages de mots clés, du flux rss, des flux externes et des billets.

2. Le paramétrage des espaces

Comme je vous l'ai expliqué précédemment, chaque espace dispose d'une signature. Pour chaque signature, on trouvera un fichier XML de configuration qui lui est propre. Ce fichier décrit les UserControls à afficher et leurs localisations

2.1. La MasterPage, coeur de la disposition

On utilise ici la nouveauté du Framework 2.0 qu'est la masterPage. Schématiquement, il y a 4 zones dans la page :

• Le haut de l'interface
• Le contenu, au centre
• La zone de droite
• Le bas de page

Chaque zone est en fait un ContentPlaceHolder dans lequel les contrôles de base sont incorporés. Pour chaque zone, on dispose en plus de deux autres ContentPlaceHolder qui permettent d'intégrer dynamiquerment des UserControls dynamiquement. Dans les faits, la plupart des pages est vide, et c'est le paramétrage des espaces qui détermine le contenu.

2.2. Le fichier XML de paramétrage de l'espace

Lorsqu'une page est appelée, une variable de contexte détermine l'espace en cours et la signature de la page. Par défaut, il y a 4 signatures :

• DEFAUT, c'est à dire la page récapitulative
• VOIR, lorsque l'on visualise un billet particulier
• TAG, pour le résultat d'une recherche par mot clé
• ARCHIVES, lorsque l'on demande les publications d'un mois donné

Etant donné qu'il existe un fichier de paramétrage XML par espace, il est alors chargé dynamiquement puis désérialisé. Cela permet ensuite en fonction de la signature disponible dans le contexte, de charger dans chaque zone les UserControls adéquates. Il est aussi possible d'ajouter du code statique au dessus de la barre de navigation, personnalisant un peu plus le portail. Le thème peut aussi être affecté à l'espace. Il est indiqué dans la table du SiteMap et sera automatiquement appliqué. Il s'agit ici ni plus ni moins de l'exploitation de la notion de Theming d'ASP.Net 2.0.

Il est possible de passer des paramètres au UserControl non pas via une Interface mais via une Collection d'objets. La seule contrainte est de faire dériver tous ces UserControls de Business.Page.UserControl. Dans l'exemple ci dessus, sur la page principale de mon espace et dans la zone de droite, je charge 5 UserControls que je place avant ou après les contrôles standards de ma page définis dans le default.aspx.

2.3. La réécriture d'URL

L'application se limite donc à 6 pages ASPX ! Une page par signature, plus la homepage et les flux rss du site. Tout cela est fait grâce à l'implémentation du module UrlRewriter, légèrement retouché pour fonctionner avec Ajax. La réécriture transforme un chemin en arguments dans la requete HTTP vers une page destinatrice. Les efforts ont été fait pour veiller à la sécurité des données issues de l'interprétation de la réécriture d'Url. J'ai trouvé un autre module de réécriture qui m'a l'air plutôt complet.

3. Des capacités de personnalisation entières

3.1. La notion de liste

Restant fidèle à SharePoint, j'ai conservé cette notion de liste. Une liste est un ensemble d'informations ordonnées, comme un album de photos, un flux rss, un billet. Une table unique regroupe ces listes, simplifiant grandement la couche d'accès aux données et permettant une grande évolutivité.

3.2. Le module de lecture de flux RSS

Le portail dispose d'un module AJAX permettant la lecture d'un flux RSS externe, transformé via une feuille XSL. Pensant au départ faire la transformation coté client, je suis vite tombé sur les contraintes de sécurité et de CrossSiteScripting. La transformation est générée coté serveur et renvoyée ensuite au client.

3.3. Intégration de pages personnalisées

Il est bien entendu possible d'ajouter ces propres pages. Il suffit à l'initialisation de définir manuellement la signature et l'espace ! Vous aurez la possibilité d'ajouter une nouvelle signature à votre fichier de configuration pour que votre page charge dynamiquement des contrôles. Les pages spécifiques sont placés dans un chemin particulier (/specific) pour conserver la cohérence applicative.

3.4. L'interaction sur les META tags

Les META tags sont bien entendu alimentés sur le portail. Un certain nombre de UserControls interagissent sur les contenu des tags :

4. Les sources

Les sources sont utilisables et modifiables gratuitement pour toute personne physique. Faites moi part de votre souhait d'obtenir les sources. Je me ferai un plaisir de vous les faire parvenir. Pour les entreprises, me consulter par email.