Extensible StyleSheet Language (XSL)

le HTML commence à ressortir.

 Les fichiers XSL ont une étiquette xsl:stylesheet de niveau supérieur, une étiquette xsl:output, et un ensemble imbriqué d’étiquettes xsl:template. Notez comment l’étiquette xsloutput spécifie que la sortie sera HTML. XSL n’est rien d’autre qu’un filtre. XML entre dans un filtre en XSL et il en sort en HTML.

La figure 2 montre le XML de notre exemple et la figure 5 montre la table HTML List of Accounts. Les étiquettes xsl:template contrôlent le filtrage XSL. Par analogie avec RPG, les templates XSL sont similaires aux lignes de spécification d’entrée RPG II, recherchant des caractères dans des colonnes spécifiques puis activant un indicateur qui sera utilisé par la suite pour prédire les lignes de spécification de sortie.

Les templates XSL recherchent des correspondances de noeuds XML. S’ils trouvent une correspondance, le HTML dans l’étiquette xsl:template est généré. De plus, les étiquettes xsl:template imbriquées recherchent des correspondances dans le XML qui correspondait au template conteneur. Les étiquettes xsl:template de la figure 6 posent une question : les chaînes de myNs- Slash. En effet, la figure 2 ne montre aucune étiquette XML qui corresponde au nom myNsSlash:searchResponse. J’utilise cette syntaxe à cause d’une difficulté avec le XML généré avec WebServices. WebServices pourrait avoir les namespaces XML associés à une réponse.

Dans le cas de mon exemple, ce namespace est défini en tant que targetNamespace="http://denoncourt.com" La réponse SOAP XML a les étiquettes suivantes: <searchResponse xmlns="http://denoncourt.com/" <searchReturn xmlns="http://denoncourt.com/" Au fait, le nom « denoncourt.com » vient du nom du package de la classe Java qui invoque le RPG.

 Des namespaces compliqués gênent l’écriture de XSL. Le problème peut être résolu simplement en remplaçant les déclarations namespace dans le xsl:stylesheet comme je l’ai fait en haut de la figure 6 par les lignes suivantes : xmlns:myNsSlash="http://denoncourt.com/" xmlns:myNsNoSlash="http://denoncourt.com/" J’ai créé deux noms de namespace logiques parce que, pour quelque raison, WebSphere place une barre oblique à la fin de certaines étiquettes xmlns (mais pas de barre oblique dans d’autres).

Cela étant mis à part, mes étiquettes xls:template – pour pouvoir qualifier les étiquettes searchResponse, searchReturn, number, name et balance provenant de la figure 2 – utilisent les namespaces XML myNsSlash et myNsNoSlash. Bien entendu, si vous générez vous-mêmes le XML plutôt que d’utiliser le XML généré par un service Web, vous n’aurez pas ce souci de namespace.Architectures Ajax/RPG

L’exemple de cet article utilise une architecture où le XML provient d’un service Web. Mais quelques autres architectures méritent considération. L’une est RPG CGI. Le RPG CGI répond aux requêtes Ajax par du XML généré à partir de RPG. Le codeur RPG n’a pas à se préoccuper des technologies de HTML, CSS, ou JavaScript. Et voici une autre architecture : une très fine couche de Java côté serveur peut invoquer RPG qui renvoie des jeux de résultats SQL. Les routines Java côté serveur emploient un utilitaire qui convertit les jeux de résultats SQL en XML.

Cette même stratégie fonctionne tout aussi bien avec PHP. Vous pouvez établir le code côté serveur afin qu’il n’ait pas besoin d’être modifié lorsque d’autres services sont ajoutés. Le nouveau RPG est enregistré comme une procédure stockée SQL, et vous pouvez établir le code côté serveur pour invoquer des procédures stockées par nom, comme passées par la requête Ajax. Vous pouvez employer un utilitaire générique pour définir les paramètres des procédures stockées à partir des paramètres passés par Ajax : vous devez simplement définir les types de paramètres comme chaînes.