ASP.NET 2 arrive en grandes pompes et une des nouveautés majeures annoncées s'appelle le page master(ing). Ce concept propose de mettre en œuvre l'héritage visuel de vos pages web en partant d'un modèle commun. Il ne reste plus qu'à compléter ce qui est spécifique à la page courante. Un exemple classique consiste à modéliser une page avec une zone d'entête, suivie d'un espace de contenu pour finir sur une zone bas de page.
Ce concept existe déjà depuis longtemps avec XMLRAD. Quelque soit la plateforme cible que vous allez choisir : Win32, Linux, Java ou .NET, la technique reste la même ce qui est loin d'être négligeable. Cette homogénéité indépendante des plateformes est possible car tout repose sur des technologies standards et indépendantes : XML + XSLT.
Il est probable que vous devrez relire plusieurs fois ce tuto explicatif, car il détaille de façon assez précise les éléments mis en jeu. Ce ne sera pas forcément évident de recoller tous les morceaux à la première lecture… Je préfère prévenir. La récompense est qu'une fois tout ça assimilé, le concept vous paraîtra bien plus facile que vous ne pouviez l'imaginer !
Modèle de page standard
Lorsque l'on démarre le développement d'une nouvelle page, nous créons un nouveau XMLService. Un bon nombre d'assistants nous sont proposés. Chacun d'eux produit une page plus ou moins garnie, on peut citer les DataGrid, Formulaires d'édition etc. Le modèle qui nous intéresse ici est accessible via l'assistant Divers / Fiche vide (screen_1).
Pour une page vide, c'est déjà pas mal ! Malgré cet écran très plaisant, il ne correspond pas forcément à la structure de page de base de l'application web que vous allez mettre en chantier. Voici deux screenshots d'applications réalisées avec XMLRAD. Le premier repose sur le modèle de page vide proposé par défault par XMLRAD. Le second s'appuie sur un modèle de page personnalisé, ce que nous allons apprendre à "modeler".
Modèle de page standard : Etude interne
Nous allons commencer par étudier comment est conçu le modèle de page standard, matérialisé sous la forme d'un template xsl nommé xslc:Page.
Ce tutorial n'a pas vocation à expliquer les différentes étapes du workflow de génération d'un écran, rappelons juste que des grappes de données XML sont initialisées, chargées et/ou générées à partir de sources multiples, et qu'un processeur XSLT parcourt ces données et exécute des actions de transformation de ces données. Le résultat de ces transformations est le plus souvent un flux HTML : la page web affichée par notre navigateur.
Quand on parle d'une page de base, on doit aussi évoquer les données de base sur lesquelles doit s'appuyer le template xslc:page ou celui que nous allons personnaliser.
Voyons donc les données xml disponibles par défaut pour le processeur xslt lors de l'invocation de notre page vide. Pour cela, sélectionnez le XMLService respectif, et cliquez sur le menu XML. Les données XML apparaissent sur la moitié droite de l'écran (screen_3) :
les XMLC_Params qui sont un mix de variables de fonctionnement de l'application
les XMLC_Profile qui sont des données personnelles du profil de l'utilisateur courant
les Aliases qui énumèrent un certain nombre de chemins
les Locales qui constituent un dictionnaire de données (multilingue)
La racine de ces données xml est toujours <document>, ceci nous intéresse particulièrement ici.
Voyons maintenant comment notre page de base est générée au niveau du processeur xslt. Cliquez sur le menu XSL du XMLService pour visualiser le code xslt ou ouvrez le dans un éditeur spécialisé tel qu'XMLSpy. La feuille xslt commence par matcher la racine du document xsl :
Le template document déclenche aussitôt un autre template nommé : xslc:Page avec un certain nombre de paramètres. Revoyons notre feuille xslt sous forme de vue grille arborescente (screen_4) :
Le modèle de page vide xslc:Page fourni en standard par XMLRAD est ici appelé avec les paramètres :
Title
PageTitle
ToolbarButtonsLeft
ToolbarButtonsRight
ActionMenu
Body
Allons voir d'un peu plus près ce template xslc:Page. Mais où est-il caché ?
Il est défini dans un fichier xslc.xsl. Ce fichier important regroupe quasiment tous les composants xsl (qui sont des templates xsl nommés) de l'environnement XMLRAD.
Il existe autant de copies de ce fichier que d'applications XMLRAD, autrement dit la librairie de composants xsl est propre à chaque application.
On peut donc la modifier sans que cela ait des répercussions sur l'ensemble des applications ou sur l'environnement lui-même.
Ce fichier réside dans le sous dossier \Bin\XML de l'application (screen_5) :
Ce template est très complet donc très long, on ne va parler que de certaines parties.
La première partie consiste en la déclaration de plusieurs paramètres, suivi des variables (xsl:variable). Ensuite commence la production de flux html, qui commence par la balise racine d'une page web : <html>. A partir de ce moment, des balises html vont être générées selon les paramètres et les variables du template xslc:Page.
Notez que ce template prend en compte les skins, on voit par exemple pas très loin après <html> la déclaration de <body> :
Les skins permettent de personnaliser le visuel de vos écrans en fonction des paramètres d'application ou de l'utilisateur connecté. Le framework remonte le skin à utiliser dans <document><XMLC_Params><XMLC_Skin> (cf. notre grappe xml ci-dessus).
La variable $XMLC_SkinPath est déclarée en tête du fichier xslc.xsl de sorte que cette variable soit accessible à tous les templates xslt, qui peuvent s'appuyer dessus pour accéder à des ressources graphiques dans le dossier du skin respectif. Voici comment est déclarée la variable $XMLC_SkinPath :
Elle représente le chemin d'accès d'un dossier respectif à un skin, racine des ressources graphiques de l'application. De fait, pour notre future page de base, on fera attention à bien préfixer les chemins des ressources graphiques par {$XMLC_SkinPath}.
Comment modifier le template xslc:Page ?
C'est une question délicate. En réalité la vraie question devrait être : Faut-il modifier le template xslc:Page ? Ce n'est pas recommandé par l'éditeur car ce template peut évoluer au fil des versions de XMLRAD, et rien ne garantit une compatibilité descendante du fait de vos modifications. Précisons que si on modifie le template, cela ne concerne que l'application en cours et pas l'ensemble des applications que vous développerez avec XMLRAD, car les fichiers templates xsl sont recopiés dans le repertoire de chaque application.
Pourtant, nous souhaitons modifier ce template car notre objectif est de définir un master de page !. Alors que faire ? Soit on doit trouver une autre solution, soit on transgresse les recommandations tout en gardant à l'esprit les contraintes qui peuvent en découler. J'ai choisi ici la deuxième option, mais… :
Il existe cependant une solution alternative qui permet de ne pas toucher au xslc:Page ! C'est une solution plus propre mais plus complexe à mettre en œuvre, donc elle fera l'objet d'un autre tutorial qui sera la suite de ce que vous êtes en train de lire.
Revenons à nos moutons, on se demandait : Comment modifier le template xslc:Page ?
Il faut déjà se demander quels paramètres on veut continuer de prendre en compte, et le cas échéant bien les prendre en charge dans notre modèle. Par exemple, notre nouveau modèle aura-t-il besoin d'un ActionPanel ou pas ? Si non alors on peut supprimer le bloc <xsl:param name="ActionMenu"/>. Si on oublie d'enlever la déclaration du paramètre, ce n'est pas grave non plus, car si non utilisé il est simplement ignoré par le processeur xsl.
Une fois les choix de paramètres effectués, on tend ensuite vers de la conception html assortie de quelques injections de xslt. Il faut enfin se demander si on ne veut pas rajouter de paramètres supplémentaires à notre modèle, paramètres qu'on devra gérer nous même.
Il faut avoir à l'esprit que les autres assistants XMLService (autres que Divers / Page vide) font aussi appel à xslc:Page, mais ils ajoutent un contenu plus garni au paramètre Body. Pour cette raison, il est préférable parfois de conserver ce paramètre Body car les autres assistants pourront insérer leur contenu dans votre modèle de page via ce paramètre Body.
Récapitulons :
on fait le tri dans les paramètres pris en charge ou pas par notre modèle
on conserve éventuellement le paramètre Body
on définit notre nouveau modèle de page, dans lequel on prévoit un espace pour inclure le contenu du paramètre Body.
Exemple : Maintenant créons un modèle de page simple avec seulement deux paramètres :
le paramètre Body
un nouveau paramètre nommé Date (pour dire si on affiche la date du jour ou pas)
Ce modèle est le suivant : un espace pour le menu, un pour le contenu et un pour le bas de page. La date irait dans le bas de page. Nous choisissons des couleurs harmonieuses, de façon à bien distinguer chacune des parties de la page html (screen_6) :
Nous allons intégrer cette structure html à l'intérieur du template <xslc:Page>. On commence par éliminer tous les paramètres et variables pris en charge par l'ex template xslc:Page, sauf le paramètre Body :
Remarquez l'emplacement de l'instruction <xsl:copy-of select="$Body"/> qui va copier le contenu du paramètre Body. Ca y est, vous avez personnalisé le composant "page vide". Voyons le résultat (screen_9) :
Vous pouvez remarquer que le template xslc:Page produit le résultat escompté, et que l'onglet "FormBase" et l'espace visuel associé sont le résultat d'éléments passés au paramètre Body.
On peut ajouter que les paramètres "title", "PageTitle", "ToolbarButtonLeft" etc. n'ont plus besoin d'être spécifiés lors de l'appel à xslc:Page, car notre nouveau template ne les prend pas en charge.
On pourrait ajouter par exemple : un paramètre Date dans notre template, et injecter la valeur de ce paramètre à l'endroit spécifié :
Si aucun paramètre Date n'est passé, aucune valeur ne sera insérée dans le bas de page.
Conclusion
J'espère que ce tour n'a pas été trop compliqué, que vous avez pu entrevoir les possibilités que cette technique apportait, et que cela vous permettra de structurer vos prochaines applications en pensant toujours à ce concept de modèle de page.
N'hésitez pas à disserter et débattre de ce sujet sur le forum XMLRAD, mais aussi à me poser des questions directement.
Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Responsable bénévole de la rubrique XMLRAD : Jean Philippe Bempel - Contacter par EMail :
