Discussion :

[khand]

Bonjour à tous,

Je suis en train de développer un site en PHP. Afin de faire les choses correctement, j'ai décidé d'appliquer un développement de type MVC. J'ai choisis d'utiliser XSLT pour le coté présentation. Mon problème est le suivant : j'aimerais avoir plusieurs feuilles de style XSLT pour générer mes pages HTML. Et donc de pouvoir découper en bout de code xslt réutilisable. Là où ca coince, c'est que j'aimerais pouvoir mettre mes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:include href="header.xsl" />

où je le désire dans mon code, et non pas directement après l'instruction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:output method="html" encoding="UTF-8" />

.
Si je le change de place (entre deux balises html), j'obtiens une erreur.

Pouvez-vous m'aider ?

Merci beaucoup

[thelvin]

Pouvez-vous m'aider ?

Ce n'est pas comme ça qu'on utilise XSLT. Là tu essaies de faire du PHP avec XSLT. Ce n'est pas possible.
Ce que tu peux faire, c'est organiser tout ton XSLT en templates, de sorte qu'un template soit aussi petit que possible et repose autant que possible sur des call-template.
Ainsi, les templates peuvent être éclatés en une multitude de feuilles XSLT qu'on peut choisir d'inclure ou pas dans la feuille principale.


Ce que tu nous décris toi, c'est un seul template match="/" géant, qui fait absolument tout ou presque sans en appeler d'autre. Et cela ne permet pas d'éclater en plusieurs fichiers, c'est une manière de faire PHP, pas XSLT.
Ce qui m'amène à mon deuxième point : autant je supporte mal le langage PHP, autant il me semble particulièrement bien adapté comme langage de présentation. Lui c'est tout-à-fait dans sa logique de faire ça, et il est facile de lui construire un modèle bien intégré.
Alors pourquoi aller vers autre chose, quand on est déjà en train de faire du PHP ?

[khand]

Bonjour,

Merci pour ta réponse. Tu as très certainement raison quand à ma mauvaise utilisation de XSLT. Mais j'en suis actuellement au début, et j'aimerais grandement appréhender ce langage de présentation. C'est d'ailleur pour celà que je m'éforce de l'utiliser, afin d'en comprendre tout les rudiments. Et ce malgré le fait qu'un autre language soit peut être plus adapté.

Celà étant dit, j'ai toujours considéré que le PHP était un language particulièrement adapté à discuter avec un SGBD plutôt que de la mélanger avec la présentation. Mais, encore une fois, c'est surement ma petite connaissance de PHP qui parle...

Maintenant tu viens de me mettre sur une piste avec la fonction call-template. Je vais donc essayer d'utiliser conjointement xsl:include et xsl:call-template afin de produire une fichier XSLT cohérent.

D'avance merci.

Khand

[thelvin]

Je viens de me rendre compte que j'ai dit une grosse bêtise.

J'ai parlé d'utiliser au maximum call-template.
Je voulais dire, utiliser au maximum apply-templates (ou call-template quand c'est adapté.)

Ce qui est important, en fait, c'est que chaque template repose autant que possible sur d'autres templates (et donc, soit lui-même aussi petit que possible.) Ce qui permet de structurer la feuille de style, et de l'éclater en plein de fichiers, vu qu'une feuille applique les templates des feuilles qu'elle inclut, et peut les appeler.


Concernant PHP qui soit un bon langage de présentation, disons que ça peut être une question de goût. Je n'aime pas ce langage, mais en temps que langage de présentation je trouve qu'il ressemble aux JSPs. Et ce n'est pas mal quand on a un modèle bien fait.
XSLT, c'est fait pour transformer du XML, autrement dit dans ton cas tu te forces à représenter ton modèle en XML... Ça peut être bien comme ça peut être pas bien ou entre les deux, mais dans ta situation, je ne vois pas l'intérêt.

[GrandFather]

Pour les constructions de feuilles de style modulaires et évolutives, XSLT dispose de mécanismes assez évolués:

• Inclusion avec xsl:include
• Import avec xsl:import (et xsl:apply-imports)
• Templates nommés avec xsl:template name="..." et xsl:call-template

Il existe d'autres possibilités plus exotiques, comme par exemple d'écrire du code XSLT paramétrable qui génère du XSLT, mais les 3 mécanismes listés ci-dessus permettent déjà de couvrir la grande majorité des besoins.

L'inclusion permet de factoriser des templates nommés ou non entre diverses feuilles de style, tandis que l'import ajoute des possibilités POO à XSLT, les templates importés jouant le rôle de « classes parentes » par rapport aux templates de la feuille de style qui les importe.

Les templates nommés font eux office de fonctions, puisqu'ils peuvent être appelés avec xsl:call-template en dehors de tout contexte d'évaluation du document d'entrée.

Ça peut être bien comme ça peut être pas bien ou entre les deux, mais dans ta situation, je ne vois pas l'intérêt.

Au contraire, c'est l'idéal dans un contexte MVC. On a ainsi une séparation conceptuellement parfaite entre la couche Vue (présentation) écrite en XSLT et les autres écrites en PHP, XML servant à véhiculer les données entre elles.

[Loceka]

L'inclusion permet de factoriser des templates nommés ou non entre diverses feuilles de style, tandis que l'import ajoute des possibilités POO à XSLT, les templates importés jouant le rôle de « classes parentes » par rapport aux templates de la feuille de style qui les importe.

Tu peux en dire plus sur la différence entre ces deux fonctions (c'est surtout le côté POO que je vois pas ) ?

[thelvin]

Ça peut être bien comme ça peut être pas bien ou entre les deux, mais dans ta situation, je ne vois pas l'intérêt.

Au contraire, c'est l'idéal dans un contexte MVC. On a ainsi une séparation conceptuellement parfaite entre la couche Vue (présentation) écrite en XSLT et les autres écrites en PHP, XML servant à véhiculer les données entre elles.

Intérêt d'une telle chose entre une application et elle-même, là où la solution directe est mieux intégrée ?

[GrandFather]

Tu peux en dire plus sur la différence entre ces deux fonctions (c'est surtout le côté POO que je vois pas ) ?

xsl:include, c'est grosso modo comme un require() en PHP ; les templates inclus se comportent comme les autres templates de la feuille de style où figure la directive, et ont le même niveau de priorité.

xsl:import, c'est plus subtil. Les templates importés ne sont pas intégrés dans une seule et même feuille de style comme avec xsl:include, mais sont placés dans une arborescence d'importation qui fonctionne d'une manière assez similaire à celle d'un arbre d'héritage. Les templates ont une priorité décroissante au fur et à mesure qu'on descend cet arbre d'importation ; ainsi les templates de la feuille de style qui importe toutes les autres ont une priorité supérieure à toutes les autres.

Lorsque le processeur XSLT recherche un template à exécuter, il le recherche d'abord dans les templates de priorité maximale, puis s'il n'en trouve pas remonte l'arbre d'importation jusqu'à en trouver un. On retrouve ce mécanisme en POO lors d'appel de méthodes virtuelles.

On peut, à l'intérieur d'un template, demander explicitement au processeur d'exécuter des templates situés plus bas dans l'arbre d'importation avec xsl:apply-imports. Un peu l'équivalent d'un parent:: en PHP.

Intérêt d'une telle chose entre une application et elle-même, là où la solution directe est mieux intégrée ?

Comme toujours, pour considérer un choix d'outil il faut s'éloigner un peu du seul aspect fonctionnel et considérer les possibilités d'évolution et d'interopérabilité offertes.

En utilisant un moteur de templates XSLT dans un contexte MVC, on rend comme je l'ai dis la couche Vue totalement indépendante du reste de l'application ; cela veut dire que si par exemple dans le cas d'un refactoring complet de l'application PHP est abandonné pour un autre langage, on pourra réutiliser telles quelles les vues XSLT, sans en changer une ligne. Pas négligeable, sachant que pour un développement Web 2.0 c'est l'IHM qui bouffe le plus de temps de développement dans la plupart des projets.

XSLT étant un outil largement répandu et existant depuis plus de 10 ans, il existe énormément de feuilles de style disponibles, généralement en Open Source, qui permettent de transformer des formats XML documentés et/ou normés (Docbook, ODF, etc.) vers d'autres formats XML tout aussi normés ou répandus (XHTML, RSS, etc.). Il suffit donc de coder des modèles (le M de MVC) qui produisent du XML selon ces formats et d'adapter légèrement du code XSLT existant pour produire les vues. Gain de temps considérable.

Enfin, XSLT étant du XML qui est lui-même un langage de balises, il est reconnu et facilement manipulable par les outils d'édition dont se servent les graphistes et concepteurs Web. Chose que ces derniers apprécient énormément quand ce sont eux qui ont la charge de la construction des vues, comparativement à du PHP généralement mal supporté.

[khand]

xsl:include, c'est grosso modo comme un require() en PHP ; les templates inclus se comportent comme les autres templates de la feuille de style où figure la directive, et ont le même niveau de priorité.

...

Enfin, XSLT étant du XML qui est lui-même un langage de balises, il est reconnu et facilement manipulable par les outils d'édition dont se servent les graphistes et concepteurs Web. Chose que ces derniers apprécient énormément quand ce sont eux qui ont la charge de la construction des vues, comparativement à du PHP généralement mal supporté.

C'est en effet tous ces avantages qui m'ont poussé a utiliser XSLT. Étant au début de mon application web, et ne sachant pas vraiment vers où elle va évoluer, je voulais absolument mettre les meilleures briques possible, point de vu architecture.

Il est vrai que je pourrais très bien utiliser un autre langage pour gérer mes vues, mais je trouve intéressant de découvrir un *nouveau* (pour moi) langage. C'est l'occasion d'apprendre.
Mais encore une fois, mes échanges entre mon modèle(M de MVC) et mon contrôleurs se faisant via du XML, je pense mon utilisation d'XSLT tout a fait adapté.

Par contre ma manière de l'utiliser, doit très probablement gagner en expérience

Voici comment je m'y prends..

Mon fichier appelé par ma vue (V de MVC) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">       
  	<xsl:import href="../stylesheet/head.xsl"/>
	<xsl:import href="../stylesheet/header.xsl"/>
	<xsl:import href="../stylesheet/table_parties.xsl"/>
	<xsl:template match="/" >
	<html>
		<head>
			<xsl:call-template name="head" />
		</head>
		<body>
			<xsl:call-template name="header" />
			<xsl:call-template name="table_parties" />
		</body>
	</html>	
	</xsl:template>	     
</xsl:stylesheet>

Exemple de fichier *inclut*:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:template name="table_parties">
	<table border="1">                    
	        <xsl:for-each select="parties/party">
	            <tr>
	                <td><xsl:value-of select="party_id"/></td>
	                <td><xsl:value-of select="add_country"/></td>
	                <td><xsl:value-of select="add_city"/></td>
	                <td><xsl:value-of select="add_str_name"/></td>
	                <td><xsl:value-of select="place_tot"/></td>
	                <td><xsl:value-of select="places_free"/></td>
	                <td><xsl:value-of select="name"/></td>
	                <td><xsl:value-of select="surname"/></td>
	                <td><xsl:value-of select="email"/></td>
	            </tr>
	        </xsl:for-each>
	    </table>     		
	</xsl:template>
</xsl:stylesheet>

Merci pour vos réponses.

Khand

[Loceka]

les templates de la feuille de style qui importe toutes les autres ont une priorité supérieure à toutes les autres.

Merci pour ton explication. :awe:

Question con : est-ce que, comme en POO, lorsqu'une template est redéfinie dans une feuille de style "fille", un appel de la "mère" à cette template va exécuter la template fille ?

Exemple (je sens que c'est pas clair pour tout le monde ):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<!-- Template fille -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:import href="mere.xsl"/>
 
	<xsl:template match="/">
		<xsl:call-templates name="mere"/>
		<xsl:apply-templates select="test"/>
	</xsl:template>
 
	<xsl:template match="test">
		<xsl:value-of select="'Template fille.'"/>
	</xsl:template>
</xsl:stylesheet>
 
<!-- Template mère -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:template name="mere">
		<xsl:apply-templates select="test"/>
	</xsl:template>
 
	<xsl:template match="test">
		<xsl:value-of select="'Template mère.'"/>
	</xsl:template>
</xsl:stylesheet>

Dans un contexte Objet (en Java par exemple) ça retournerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Template fille.
Template fille.

Est-ce que c'est le cas ici ? (j'ai essayé de faire le test mais j'utilise Firefox pour faire la transformation et apparement il n'aime pas trop les import (ou c'est ma syntaxe qui est mauvaise)).

@khand :

Est-ce que ça fonctionne comme tu le souhaites ou est-ce que ça ne fonctionne pas ? (dans ce cas où, avec quelle erreur, ...)

[khand]

Alors, ca fonctionne plutôt bien ! Je voulais juste partager ma solution afin de m'exposer a des remarques constructives

Encore merci pour la qualité de vos réponses !

[GrandFather]

Question con : est-ce que, comme en POO, lorsqu'une template est redéfinie dans une feuille de style "fille", un appel de la "mère" à cette template va exécuter la template fille ?

C'est le cas. Mais attention à la terminologie et à ne pas pousser l'analogie trop loin: un apply-templates n'est pas un appel de méthodes, mais la sélection (avec l'attribut select) d'un ensemble de nœud et la recherche par le processeur XSLT du (ou des) template(s) dont l'attribut match « correspond » à ces nœuds et leur exécution. Il n'y a donc pas vraiment de notion d'héritage en XSLT, mais une notion de priorité entre les templates, sachant que les templates importés ont une priorité inférieure à celle des templates de la feuille de style qui importe.

Dans un contexte Objet (en Java par exemple) ça retournerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Template fille.
Template fille.

Est-ce que c'est le cas ici ? (j'ai essayé de faire le test mais j'utilise Firefox pour faire la transformation et apparement il n'aime pas trop les import (ou c'est ma syntaxe qui est mauvaise)).

C'est effectivement le cas. Et c'est xsl:call-template, pas xsl:call-templates.

Une illustration de l'appel explicite d'un template importé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<!-- Template fille -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:import href="mere.xsl"/>
 
	<xsl:template match="/">
		<xsl:apply-templates select="test"/>
	</xsl:template>
 
	<xsl:template match="test">
		<xsl:value-of select="'Template fille.'"/>
                <xsl:apply-imports />
	</xsl:template>
</xsl:stylesheet>
 
<!-- Template mère -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:template match="test">
		<xsl:value-of select="'Template mère.'"/>
	</xsl:template>
</xsl:stylesheet>

@khand >> L'utilisation de templates nommés (qu'on appelle avec xsl:call-template) dont le code fait référence à des nœuds du XML d'entrée disponibles uniquement dans un contexte précis est généralement une mauvaise idée... Une bonne pratique consiste à ce que les templates nommés ne travaillent soit que sur des données transmises par xsl:with-param, soit fassent référence à des nœuds du document mais avec un chemin xpath absolu.

Pour finir, un autre argument, technique celui-là, en faveur de l'usage de XSLT comme moteur de templates: la possibilité de faire le rendu HTML sur le client plutôt que le serveur, pour répartir les charges. Tous les navigateurs modernes et répandus ont maintenant un processeur XSLT fonctionnel.

[Erwy]

xsl:include, c'est grosso modo comme un require() en PHP ; les templates inclus se comportent comme les autres templates de la feuille de style où figure la directive, et ont le même niveau de priorité.

Une petite précision par rapport à la priorité : un xsl:include est fils de xsl:stylesheet mais il ne nécessite pas d'être déclaré au début.
S'il est déclaré entre des templates, celles qu'il ajoute seront considérées comme apparaissant à cet endroit.
Comme sur les priorités par défaut, l'ordre de déclaration est un facteur non négligeable, il faut en tenir compte.Le dernier déclaré est le plus prioritaire en cas de "conflit"

Le xsl:import lui doit absolument être déclaré derrière le xsl:stylesheet ou derrière un autre xsl:import.Entre eux les xsl:import suivent aussi les règles de priorité de placement, un extrait de la norme qui expliquera ça plus en détail :

For example, suppose

*

stylesheet A imports stylesheets B and C in that order;
*

stylesheet B imports stylesheet D;
*

stylesheet C imports stylesheet E.

Then the order of import precedence (lowest first) is D, B, E, C, A.

[GrandFather]

Une petite précision par rapport à la priorité : un xsl:include est fils de xsl:stylesheet mais il ne nécessite pas d'être déclaré au début.

C'est aussi le cas de require(), et m'adressant à un développeur PHP je n'ai pas jugé nécessaire d'apporter cette précision.

Ta remarque quant aux risques induits par un xsl:include provoquant des conflits avec d'autres templates est pertinente, et j'ajouterai qu'il est généralement symptomatique d'une mauvaise conception d'avoir des templates de même priorité se « recouvrant », et que ce soit leur ordre d'apparition qui décide de leur usage. La spécification du W3C est d'ailleurs un peu trop laxiste à ce sujet, en laissant optionnel et à la discrétion des concepteurs de processeur XSLT le déclenchement d'une exception quand cela arrive. Car ce n'est pas toujours volontaire, et la détection du bug n'est pas toujours évidente.

Pour éviter ce genre d'effet de bord, il faut soigner l'écriture des attributs « match », et ne pas hésiter à utiliser l'attribut « mode », de façon à ce que les templates s'excluent mutuellement.

[Erwy]

C'est aussi le cas de require(), et m'adressant à un développeur PHP je n'ai pas jugé nécessaire d'apporter cette précision.

Je m'en doutais un peu mais comme je ne connais rien à PHP j'ai pensé aux autres personnes partageant mon sort .

Je n'aime pas trop jouer avec le mécanisme des priorités (la dernière fois c'était pour virer des noeuds vides , prédicats prioritaire sur non predicat) et celui du "dernier qui parle à raison" je l'aime encore moins et ne l'ai jamais utilisé,trop dangereux à mon gôut (et manque de lisibilité).
Le problème du xsl:include, de mon point de vue, par rapport au xsl:import c'est que tu ne sais pas nécessairement ce que tu appelles si tu n'as pas la main exclusive sur le fichier en question.
Je trouve que le xsl:import est un peu plus sécurisé de ce point de vue