Delphi ASP.NET Portal Starter Kit v.1.0 (DPSK)Date de publication : 18/05/2005 , Date de mise à jour : 30/07/2005
Par
Pascal Chapuis (ChapsandChips) Cet article présente le projet "Delphi ASP.NET Portal Starter Kit". Ce projet permet très simplement de créer et de maintenir un portail Internet intégrant la gestion de contenu. Les fonctionnalités et l'implémentation sont présentées. Les principales carences de ce projet sont listées. Une série d'améliorations est proposée. 1. Présentation générale - fonctionnalités intégrées 1.1. Origine du projet initial 1.2. Portail Internet et gestion de contenu (CMS) 1.3. Arborescence, page modèle et Modules 1.4. Liste et définition des Modules enfichables 1.5. Sécurité via les rôles 1.6. Accès pour les périphériques mobiles 1.7. Qualité de service (QOS) et Cache 2. Présentation technique du projet Delphi 2.1. Composantes logicielles 2.2. Pourquoi une traduction Delphi ? 2.3. Configuration XML 2.4. Modules enfichables 2.5. Utilisateur et Rôle : sécurité 2.6. ASP.NET Mobile 2.7. Fonctionnement du cache 3. Carences de cette version 3.1. Configuration "PortalCfg.XML" et HttpContext.Current 3.2. Ordre des onglets et des modules 3.3. Accès ADO à différentes bases de données 3.5. Divers 4. Améliorations proposées 4.1. Edition de contenu et granularité des primitives d'édition 4.2. Validation de la publication : modérateur 4.3. Portail Multilingue 4.4. Personnalisation de la charte graphique 4.5. Arborescences et onglets (tabs) 4.6. Modules supplémentaires 4.7. Modules pluggables de Dot Nuke Net et Interfaces 5. Conclusion 6. Références 6.1. Microsoft ASP.NET 6.2. Delphi ASP.NET Portal Starter Kit 6.3. Autres projets de portail Internet 7. Remerciements 1. Présentation générale - fonctionnalités intégrées
Cette présentation générale présente les fonctionnalités principales du projet. Ces caractéristiques sont nécessaires à un portail Internet intégrant la gestion de contenu.
Cette première partie se veut plus fonctionnelle que technique. Cette première partie conviendra au lecteur peu technicien mais désireux de comprendre les fonctions essentielles
présentes dans ce projet.
1.1. Origine du projet initial
Le projet ASP.NET Portal Starter Kit a été initialement publié par Vertigo Software en Novembre 2002. La création de ce projet fut motivée par le besoin
de fournir des projets de démonstration accompagnant la nouvelle technologie ASP.NET. Ainsi une gamme de différents Starter
Kit est née.
La liste des différents "ASP.NET Starter Kit" disponibles est la suivante :
Ces différents projets sont proposés dans les langages VB#, J# et C# et sont en téléchargement gratuit sur le portail
Microsoft dédié à ASP.NET.
1.2. Portail Internet et gestion de contenu (CMS)
Les deux niveaux suivants sont à distinguer :
La principale caractéristique du Portal Starter Kit est l'intégration en ligne de la gestion de contenu
(CMS). Ainsi le portail offre deux modes de fonctionnement principaux :
1.3. Arborescence, page modèle et Modules
L'arborescence principale du portail est représentée via un système d'onglets.
Chacun de ces onglets correspond à une page du portail. Cette arborescence est administrable en ligne via la page d'administration.
Cette administration permet la gestion une d'une arborescence dynamique.
Chaque page du portail implémentée via Portal Starter Kit est composite et donc créée dynamiquement.
Cet assemblage est basé sur une page modèle ou gabarit. Cette page modèle inclut trois zones : la zone gauche, la zone du centre
et la zone de droite. La page d'administration de la présentation permet de positionner les modules d'une page du portail dans ces zones.
La page modèle est composée d'une partie représentant la banière du site. Dans cette banière sont présents le titre du site, les onglets... De même la partie titre des modules est
extraite dans un composant. Cette décomposition des pages/composants en sous-éléments permet de maintenir facilement l'aspect général du portail.
1.4. Liste et définition des Modules enfichables
La liste des modules disponibles est présentée ci-dessous. Ces modules sont groupés dans deux tableaux principaux en fonction
de leur rôle d'administration du portail ou de leur rôle de présentation de contenu.
Liste des modules d'administrations présents sur la page de gestion du site :
Liste des modules de présentation de contenu :
Module utilitaire :
A chacun de ces modules de présentation de contenu est associé un objet métier implémentant l'accès aux informations de contenu. Ces informations
de contenu sont stockées dans une base de données (SQL Server ou FireBird). Il est ainsi possible d'interfacer une base de données existante avec le portail.
Le paramétrage du contenu présenté par les modules Images et XML/XSL, n'est pas stocké dans la base de données. Dans ce cas ces paramètres sont stockés dans la configuration XML.
D'autres modules peuvent-être ajoutés (pluggable) via le module "définition de Module Type". Un module spécifique est facilement intégrable
à l'ensemble du portail. Par exemple un module "Blogs" est simple à développer et ne présente aucune difficulté d'intégration dans le portail. L'ensemble reste cohérent
grâce à ce système de modules enfichables.
1.5. Sécurité via les rôles
Le projet ASP.NET Portal Starter Kit intègre les notions de sécurité permettant une intervention sur le portail
de plusieurs intervenants (travail collaboratif). Par exemple, un portail réalisé avec ce projet convient
à un portail de communauté de communes dans lequel chaque commune est responsable de sa rubrique mais ne doit pas intervenir
sur la rubrique de la commune voisine.
Chacun des onglets du portail correspond à une page ayant des droits d'accès en consultation. Ainsi par exemple l'onglet Administration ne sera proposé qu'aux utilisateurs possédant le rôle d'administrateur. Le même principe de sécurité est valable pour les modules composant les pages. Il est donc possible de distribuer des rôles sur les pages mais aussi sur les modules. Ces rôles sont affectés à deux actions principales :
Le basculement du mode consultation vers le mode administration de contenu est effectué via la connexion au portail et via le(s) rôle(s) associé(s) au compte de connexion.
Un utilisateur lambda (public) lors de sa connexion au site ne se verra pas proposer la maintenance du site alors qu'un utilisateur connecté
par exemple comme Administrateur (rôle admin) disposera d'une interface lui permettant de maintenir en ligne le portail.
Il est possible de définir de nouveaux rôles via le module d'administration. Ces rôles sont stockés dans une table de la base de données.
Ils sont croisés avec les utilisateurs. Par exemple à l'utilisateur Administrateur est associé le rôle "Admin". Lors de l'administration, le rôle associé
à une page ou à un module est copié dans le fichier de configuration "PortalCfg.xml".
1.6. Accès pour les périphériques mobiles
Le projet ASP.NET Portal Starter Kit permet de communiquer avec un public important grâce aux fonctionnalités intégrées d'accès aux périphériques Mobiles.
Par exemple, le portail Internet d'un office de tourisme peut offrir l'accès à la liste des événements locaux via la connexion des téléphones mobiles des touristes en vacances.
Chaque page (onglet) et chaque module possèdent une option ShowMobile. Cette option, en mode administration, permet de définir si la page et/ou le module sont affichés pour les périphériques mobiles. Tous les modules ne sont pas implémentés pour permettre un affichage pour les périphériques mobiles (cf. liste des modules 1.4). Les modules "mixtes" disponibles pour les périphériques mobiles sont :
Les caractéristiques d'un périphérique mobile ne sont pas forcément compatibles avec le contenu publié sur un ordinateur. En conséquence,
deux zones distinctes (spécifiques aux périphériques de type Desktop ou de type Mobile) permettent de saisir le contenu présenté par le module.
1.7. Qualité de service (QOS) et Cache
Un système de cache configurable dans l'administration du portail permet d'offrir un temps
de réponse stable. Via ce système de cache paramètrable, les modules lors de leur création initiale sont automatiquement inscrits dans le cache du système.
Leur construction complète n'est pas nécessaire à la prochaine requête. Le HTML correspondant au module est automatiquement restitué
à partir du cache du système. Le temps de réponse (accès à la base, présentation des infos...) est ainsi optimisé au minimum.
2. Présentation technique du projet Delphi
Le projet Delphi ASP.NET Portal Starter Kit est un projet important de part sa taille. Néanmoins la complexité de l'ensemble est moindre.
Avec les contrôles utilisateurs ASP.NET (ascx), les pages (aspx) mais aussi les contrôles ASP.NET ressemblent à des poupées russes. Ceci rend le code plus digeste mais l'appréhension de l'ensemble
plus complexe. Dans cette présentation, les points clés sont abordés. Le code étant important (environ 20 000 lignes) il est ambitieux de décrire l'ensemble dans le détail.
2.1. Composantes logicielles
2.2. Pourquoi une traduction Delphi ?
Avec .NET, il est très simple d'utiliser avec Delphi les classes définies initialement en C#. Par exemple
une inclusion (uses) du namespace "ASPNET.StarterKit.Portal" permet de définir un nouveau module héritant de
la classe C# "PortalModuleControl" initiale :
Via .NET, il est également possible d'étendre une classe avec les Class Helpers ("class helper for ...").
Afin de profiter du code C#, la traduction du projet n'est donc pas forcément nécessaire. Plusieurs raisons cependant encouragent à faire cette traduction :
2.3. Configuration XML
Les informations de présentation (onglets, composition des onglets), de sécurité (rôles associés...) du portail ainsi que l'index du portail (PortalId) sont
stockées dans le fichier Portal.XML. A ce fichier correspond un mappage objet de type Stronged Typed DataSet défini dans l'unité "PortalCfg.pas".
Dans le code C# original, ce mappage (PortalCfg.cs) est automatiquement obtenu via l'utilitaire XSD.EXE du framework.
Cependant avec l'utilitaire "XSD.exe", il n'est pas possible d'utiliser le provider de code Delphi (DelphiCodeProvider). Cet utilitaire ne sait pas utiliser le fournisseur de
code Delphi. Dans ce projet, après une longue recherche pour pallier à ce problème, le fichier "PortalCfg.pas" est la traduction du fichier C# original (PortalCfg.cs) via
BabelClient. Ce service de traduction automatique de C# vers Delphi n'est pas totalement efficace, des corrections manuelles sont ajoutées dans le source du fichier "PortalCfg.pas".
Cet exemple avec FireBird réalise un mappage via une base de données vers un Stronged Typed DataSet en langage Delphi.
Structure de "PortalCfg.XML" : noeuds, pages et contrôles principaux impliqués :
Aperçu de la configuration 'PortalCfg.XML' et page et composant impliqués
Un portail est référencé par un index (PortalId) présent dans le fichier de configuration du portail (PortalCfg.xml).
Chaque page correspondante à un onglet est référencé dans un noeud "Tab". A chacun de ces noeuds correspondent les noeuds enfants des modules
assemblés par cette page. Comme pour la partie haute (bannière) de la page modèle, les modules sont eux-mêmes composites. La partie titre est implémentée dans un composant spécial.
Pour les modules standards, ce contrôle est "DesktopModuleTitle.ascx". Pour les modules spécifiques aux mobiles, le titre du module est implémenté par "MobileModuleTitle.ascx".
2.4. Modules enfichables
Les modules de présentation de contenu sont composés de deux parties principales correspondant à un contrôle de présentation et une page d'administration :
Chacun des modules de présentation de contenu hérite d'un contrôle générique "TPortalModuleControl".
Cet héritage permet d'implémenter les règles communes au portail (charte graphique, sécurité...).
Ces modules implémentent également des règles métiers spécifiques à leurs tâches (polymorphisme).
Les unités dans lesquelles sont implémentés les objets métiers d'accès au contenu sont postfixées de "DB" (par exemple ContactDB.pas).
Ces unités sont dans le répertoire : "\Components".
Un objet encapsule ces fonctionnalités. Voici par exemple la définition de l'objet métier du module "Contacts" :
Le fichier "Portal.XML" ne contient aucune donnée relative au contenu d'un module (sauf pour le cas particulier des modules "Image" et "XML/XSL"). Seuls les index et les rôles associés aux modules
sont présents dans la configuration "PortalCfg.xml". Les données correspondantes au contenu d'un module sont stockées dans une base de données (Microsoft SQL Server ou FireBird).
L'index du module est utilisé pour indexer ce contenu dans la base de données.
2.5. Utilisateur et Rôle : sécurité
Lors de l'ajout et de la composition d'une page dans le partie administration du site, les droits de consultation (AccessRoles)
de cette page ainsi que les droits en édition des modules (EditRoles) sont fixés. Ces droits sont sauvegardés dans le fichier "PortalCfg.XML" :
L'objet "PortalSecurity" défini dans l'unité \Components\security.pas possède trois méthodes permettant de tester
les paramètres de sécurité définis dans la configuration :
2.6. ASP.NET Mobile
L'accès aux périphériques mobiles utilise une page typée ASP.NET Mobile héritant de la classe .NET "MobilePage".
Comme pour les pages des périphériques de type "Desktop", une page modèle est définie : "MobileDefault.aspx"
spécifiquement pour ces périphériques.
La redirection en fonction du type de périphérique n'est pas automatique. Elle est
prise en charge par le code suivant :
La page "MobileDefault.aspx" inclut une fiche spécifique au mobile ("System.Web.UI.MobileControls.Form") et un contrôle
"TabbedPanel" défini dans l'unité "MobileControls". Ce contrôle MobileControls.TabbedPanel est équivalent aux onglets des pages pour "Desktop". Il implémente les spécificités d'un contrôle dédié aux périphériques mobiles. Il gère par exemple l'arborescence, la pagination ainsi que le type de vue de la page (SummaryView).
Ce contrôle "TabbedPanel" est encapsulé dans différents adaptateurs. Ces adaptateurs permettent la prise en charge spécifique des différents formats
(HTML 3.2, WML 1.1, cHTML) disponibles avec ASP.NET Mobile.
Pour être instanciés par le site (dans le source des pages ASPx), ces contrôles spécifiques doivent-être
enregistrés dans le fichier de configuration "Web.config.XML" du site :
Ce recensement dans "web.config.xml" fixe la relation entre un format spécifique (HtmlDeviceAdapters, ChtmlDeviceAdapters, WmlDeviceAdapters)
, un composant spécifique prenant en charge ce format et l'assemblage implémentant ce composant.
2.7. Fonctionnement du cache
Actuellement les sites Internet sont rarement adaptés pour répondre aux montées en charge.
Lors d'une vague de connexion massive, le site dans le meilleur des cas ne répond plus ou dans le pire des cas la machine/le système
passent hors service. Pour faire face à ce type de problème, un système de cache est implémenté dans le projet.
L'objet TCachedPortalModuleControl est mis en oeuvre dans la page par défaut (DesktopDefault.aspx).
Lors de la construction de la page correspondant à l'onglet selectionné, le cache est créé. Chaque module
inséré dans une page peut définir le temps d'expiration de ce cache (CacheTimeout) :
Cet objet de gestion du cache est mis en oeuvre par le framework via les méthodes "Render" (capture) et "CreateChildControls" (restitution).
La méthode "Render" surchargée permet (dans le cas ou CacheTime est différent de 0) de "capturer" le contenu HTML correspondant
à un module. Cette chaîne HTML est alors insérée dans le cache du contexte avec le timeout correspondant au cache du module correspondant :
Dans la méthode surchargée "CreateChildControls", la chaîne correspondant au module est restituée via son
chargement à partir du cache du contexte. Si la chaîne n'est pas trouvée alors le module est entièrement recréé (timeout).
3. Carences de cette version
Delphi ASP.NET Portal Starter Kit correspond à une stricte traduction du projet C# original. Bien que le projet initial
soit mature, il subsiste néanmoins quelques problèmes mineurs.
3.1. Configuration "PortalCfg.XML" et HttpContext.Current
Problème : La configuration "PortalCfg.XML" du portail est stockée dans le cache du contexte http (unité "uConfiguration.pas" : HttpContext.Current.Cache).
Lors de l'administration du site, la sauvegarde/restitution de cette configuration est parfois erronée. Ainsi les modifications ne sont pas prises en compte immédiatement.
Il peut se produire une erreur suite à la désynchronisation des informations de configuration.
Solution proposée : La configuration "PortalCfg.XML" peut être stockée dans une table de la base de données. Ce stockage offre l'avantage d'un accès transactionnel.
L'inconvénient de cette solution est un temps d'accès supérieur à celui d'un accès au cache.
3.2. Ordre des onglets et des modules
Problème : Il peut être difficile de changer la position d'un onglet ou d'un module. Ceci est principalement causé par l'algorithme simplet
d'incrémentation/décrémentation de l'index de l'élément. Les tests concernant ce problème doivent prendre en compte le problème connexe énoncé dans le point 3.1.
Solution proposée : l'algorithme de modification des index et/ou de déplacement d'un élément doit-être amélioré.
3.3. Accès ADO à différentes bases de données
Problème : Pour un besoin de code source unique et de simplicité, l'accès à la base SQL Server ou Interbase est conditionné par la directive de
compilation "SQLSERVEUR". Les composants ADO permettant cet accès sont typés et donc différents en fonction de la base de données utilisée.
Solution proposée : Il existe des composants ADO permettant un accès générique. La mise en oeuvre de tels composants permet de supprimer la directive
de compilation et ainsi d'alléger le code source d'accès à la base. Avec de tels composants, seule la chaîne de connexion conditionne le type de
base de données couplée avec le portail.
3.5. Divers
Autres imperfections diverses :
4. Améliorations proposées
De nombreuses fonctions nécessaires à un portail professionnel ne sont pas implémentées dans le projet.
Certaines de ces améliorations sont en cours de développement par l'auteur de cette version. Ces améliorations
impliquent des modifications dans les objets principaux du projet.
4.1. Edition de contenu et granularité des primitives d'édition
Carence : L'édition du contenu d'un module est en mode "tout ou rien". L'utilisateur
possédant le rôle d'administrateur accède à toutes les fonctions (insertion, édition, suppression).
Les autres utilisateurs ne possédant pas ce droit d'administration n'ont accès à aucune fonction d'édition de contenu. Il serait intéressant
de dégrader cet accès en édition pour offrir par exemple un accès "opérateur de suppression" ou encore "modérateur"...
Solution proposée : Une table énumère les différentes actions possibles en mode édition (insertion, édition, suppression, modération).
Les rôles sont associés avec les éléments de cette table. Le problème majeur de cette solution est de ne pas définir de droits relatifs
aux modules. Par exemple l'opérateur de suppression devient opérateur de suppression pour tous les modules.
4.2. Validation de la publication : modérateur
Carence : Actuellement en mode administration de contenu, les données insérées/modifiées sont immédiatement publiées.
Il est uniquement possible de modérer un module via la consultation régulière et la suppression d'un élément indésirable.
Cependant un élément indésirable peut être potentiellement consulté avant d'avoir été supprimé.
Solution proposée : Ce besoin n'est pas vraiment une exigence pour tous les modules. En conséquence, une extension des fonctions métiers
des modules concernés règlent ce problème. Par exemple pour les discussions, l'ajout d'un nouveau champ (Approuved)
de type booléan permet de vérifier si l'élément peut être publié. La valeur de ce champ est fixée à FALSE à l'insertion. Un bouton permet
de basculer l'état de ce champ à Vrai (Approuved). Ce bouton est uniquement disponible pour les utilisateurs possédant le rôle de "modérateur".
Une extension à cette solution est de stocker l'historique des modifications d'un élément. Ceci permet de suivre les différentes interventions
faites par les différents opérateurs sur un élément.
4.3. Portail Multilingue
Carence : Le portail ne propose pas le choix de la langue de publication des informations. La structure des tables et de la configuration
n'anticipe pas cette fonctionnalité de globalisation.
Solution proposée : Cette fonctionnalité est implémentée au niveau du module. Le module générique dont hérite les modules, implémente
cette fonctionnalité. Un attribut supplémentaire permet de définir la langue dans laquelle est disponible l'information. Ce choix d'un langage
parmis les langages disponibles est proposé par le module générique à l'utilisateur et à l'administrateur de contenu. Le changement de langue d'un module
doit être propagé à l'ensemble des modules de la page en cours. Ceci est effectué par une variable de session qui stocke les préférences utilisateur.
4.4. Personnalisation de la charte graphique
Carence : Une fonctionnalité standard dans les "portails Internet modernes" est la personnalisation de la charte graphique (skins). Dans le projet
Delphi ASP.NET Portal Starter Kit seule une feuille de style (ASPNETPortal.css) permet de modifier l'aspect général du portail.
Il serait intéressant d'ajouter une fonctionnalité de personnalisation graphique.
Solution proposée : La factorisation d'un module en plusieurs parties (entête, pied de page, bordure) résout en grande partie ce problème.
Ces nouvelles parties communes à tous les modules sont sélectionnées parmi une liste composée d'éléments de styles différents.
Ces différents styles sont obtenus via l'association à des feuilles de styles distinctes et/ou via une personnalisation du style HTML de l'élément factorisé.
4.5. Arborescences et onglets (tabs)
Carence : L'arborescence du site associée à des onglets est limitée. C'est une simple liste.
Il n'est pas possible de hierarchiser un élément de façon à avoir un sous-menu.
Solution proposée : Pour obtenir un arborescence plus hierarchisée, le système offre le choix du contrôle permettant la sélection de la page
en cours. Les différents choix pour ce contrôle sont : onglets ou menu. Le choix d'une arborescence de type menu entraine une modification de
la structure du fichier de configuration du site (PortalCfg.xml). Une liste de listes à n niveaux permet de proposer une arborescence de type simple (onglets)
ou complexe (menu). Associé à cette nouvelle structure, un contrôle utilisateur ASP.NET doit offrir une interface utilisateur de type correspondant (Menu).
4.6. Modules supplémentaires
Carence : Actuellement certaines fonctionnalités classiques ne sont pas implémentées. Par exemple, un module recherche n'est pas proposé.
De même, un module "lettre d'informations" serait le bienvenu. L'implémentation actuelle du portail ne traite pas l'aspect courrier électronique...
Solution proposée : L'implémentation d'un module de recherche est assez complexe car cette recherche doit être limitée au contenu du portail autorisé à
l'utilisateur (AccessRoles) effectuant cette recherche. Ainsi la recherche est dépendante de la configuration du portail associé à l'utilisateur en cours. C'est la configuration
qui donne le référentiel de recherche. Rechercher sur les modules de type "annonce, documents ou autre" semble être un critère supplémentaire intéressant pour restreindre
la recherche. La recherche sur les documents (doc, xls...) suppose l'utilisation d'un moteur de recherche permettant la recherche fulltext dans des formats variés. Microsoft Index Server
est indiqué pour ce type d'exigence.
4.7. Modules pluggables de Dot Nuke Net et Interfaces
Les fonctionnalités d'un module ne sont pas forcément nécessaires à tous les modules. Par exemple, la fonction de recherche est inutile pour une image.
Ce constat est appréhendé dans Dot Nuke Net (DNN) via les interfaces. Les nouvelles fonctions associées aux portails sont déclarées et implémentées via des interfaces.
Seul le moteur (page) est éventuellement modifié pour prendre en charge ces nouvelles fonctionnalités. Par exemple l'interface "ISearchable" est utilisée pour invoquer une recherche
sur les modules l'implémentant. Cette figure de style conceptuelle (design pattern) correspond au "décorator" ou "wrapper". Dans le cadre de l'évolution du
produit ce modèle de conception sera utilisé.
5. Conclusion
Le projet Delphi ASP.NET Portal Starter Kit est un projet important de part sa taille.
C'est un excellent exemple pour découvrir la technologie du futur que constitue Microsoft ASP.NET. Les différents
points forts de cette technologie sont inclus dans ce projet. La partie Mobile permet d'imaginer des applications Internet
jusque là difficiles à réaliser avec Delphi. Outre ce coté pédagogique, ce projet permet de réaliser simplement un portail Internet.
Un produit réellement professionnel est largement envisageable moyennant quelques jours de développement afin de compléter cette solution séduisante.
6. Références6.1. Microsoft ASP.NET
6.2. Delphi ASP.NET Portal Starter Kit
6.3. Autres projets de portail Internet
7. Remerciements
L'auteur du projet Delphi ASP.NET Portal Starter Kit, remercie très sincérement Norbert Saint Georges pour son soutien concernant ce projet
Delphi ainsi que pour l'hébergement de la démonstration du projet gracieusement offert sur Delphinaute.be.
Merci également à Bestiol pour la relecture de cet article.
|
Copyright © Mai 2005 Pascal Chapuis. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.