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 ?