Discussion :

[SONY30]

Bonjour à tous,

J'en suis au prémice du XML mais j'aimerais avoir vos avis éclairés sur mes besoins.
Depuis un fichier XML (généré côté serveur en Java) résultant d'une recherche, j'aimerais mettre en forme ce résultat. C'est là que j'entends parler du XSL et des transformations XSLT. En fouillant un peu sur ce forum, je vois que l'on peut faire cette transformation là depuis le client ou depuis le serveur. Surtout n'hésitez à m'interrompre si j'ai tout faux.

Côté Client
Mon XML et mon XSL sont générés sur le serveur.
Et là par JavaScript et ActiveX, j'effectue ma transformation XSLT et obtient du code HTML.
Et je peux gérer les tris, le multi page, en passant des paramètres à mon XSL.

Avantages :
- Non rechargement de la page
- Aucune autre interrogation de la base pour la génération du XSL

Inconvénients :
- Stockage physique d'un fichier XSL sur le serveur.
- ActiveX : Non compatible selon les navigateurs.
- lourdeur : Si XML important, temps de transformation ?

Côté Serveur
Mon XML et mon XSL sont générés sur le serveur. J'opère également ma transformation XSLT (via JAXP) sur le serveur, qui retourne au poste client du HTML.
Là par contre pour la gestion des tris, du multipage je suis obligé de refaire appel au serveur et de recharger le client.

Avantage :
- Peu importe le navigateur du client

Inconvénient :
- Rechargement de la page
- Ré-interrogation de la base.


Tout ça n'est peut être pas très clair... Mais j'aimerais savoir si d'une part j'ai bien tout saisie et d'autre part quelle serait la meilleure solution pour vous ?

Merci d'avance.

[Erwy]

Coté client je ne connais que deux navigateur qui font correctement le boulot:
IE et FIREFOX le pb étant qu'ils n'ont pas tout le temps la même syntaxe (il existe un script sarissa pour ça mais je ne l'ai jamais utilisé)et "petit bonus" que bcp oublie qu'ils n'ont pas toujours le même ordre de parsage.
Ainsi, si mes souvenirs sont bon, msxml parse l'axe des ascendant dans le sens contraire de celui de la norme ce qui impose quelques "trucs" pour obtnir le même fonctionnement dans les deux.

Coté serveur : tu élimine ce type de pb mais tu te passes par exemple des tris et filtre coté client .

Personellement , etant sur un intranet ou je n'ai qu'a m'ocuper d'un seul type de navigatueur je le fais sur plusieurs niveau

-je recupere un xml de ma base via des procedures stockés
- je modifie, joint, elimine les doublons sur les serveurs
- quand j'ai besoin de fonctionnalité de tri/filtre sur mes ecrans je met le xml coté client autrement je fais la transformation coté serveur

[GrandFather]

Il y a un autre élément qui plaide en faveur des solutions serveur, c'est la possibilité de mettre en cache sources XML et feuilles de style XSL, voire de compiler ces dernières (avec XSLTC pour une plateforme Java) ce qui n'est pas possible côté client.

Au fait, quand tu dis que le XSL est généré par le serveur, c'est rarement le cas, on travaille plutôt avec des feuilles de style XSL statiques écrites « à la main ». Les cas où il est nécessaire de générer dynamiquement du code XSLT sont plutôt rares (et souvent complexes).

[SONY30]

Justement si, pour ma part le XSL sera généré par le serveur; puisque je ne sais pas ce que j'aurais dans mon fichier XML.

J'explique mes besoins.
En fait un utilisateur effectue une recherche, il défini des attributs, des critères, et mon moteur (Java) me retourne ce résultat dans un fichier XML. Mon besoin est donc de mettre en forme ce fichier XML.
Je pensais qu'en générant un fichier XSL cela me permettrait de gérer facilement les besoins du style (Rupture, Tri, Filtre, Multi Pages, Calcul,...); ces procédures s'effectuant côté client.

Maintenant je me pose la question : Quel intérêt de générer du XSL, puis appliquer une transformation pour obtenir du HTML côté serveur ?
Autant générer du HTML directement...

[GrandFather]

Je pensais qu'en générant un fichier XSL cela me permettrait de gérer facilement les besoins du style (Rupture, Tri, Filtre, Multi Pages, Calcul,...); ces procédures s'effectuant côté client.

Il n'est pas absolument pas nécessaire de générer du XSLT pour faire cela ; pour donner un comportement dynamique à une feuille de style XSL statique, il suffit de lui passer les paramètres - avec <xsl:param> - qui définissent ce comportement.

[Erwy]

Maintenant je me pose la question : Quel intérêt de générer du XSL, puis appliquer une transformation pour obtenir du HTML côté serveur ?
Autant générer du HTML directement...

Justement à cause du passage de paramètre coté client.
On peut grace à cela réafficher des données tries ou filtrer sans avoir besoin de rappeler le serveur et d'y stocker le xml ou de rappeller la base

voir ici pour un exemple de passage de paramètre:
http://www.developpez.net/forums/sho...93&postcount=3

Mais je ne le conseille que si on maitrise le client utilise (ce qui est mon cas).C'est alors d'un grand confort

[SONY30]

Il n'est pas absolument pas nécessaire de générer du XSLT pour faire cela ; pour donner un comportement dynamique à une feuille de style XSL statique, il suffit de lui passer les paramètres - avec <xsl:param> - qui définissent ce comportement.

Je suis d'accord avec vous.
Mais là je reviens aux inconvénients de la transformation côté client, à savoir :
- ActiveX : Gestion différente selon les navigateurs.
- Lourdeur : Si XML important, temps de transformation.

[Erwy]

Je suis d'accord avec vous.
Mais là je reviens aux inconvénients de la transformation côté client, à savoir :
- ActiveX : Gestion différente selon les navigateurs.
- Lourdeur : Si XML important, temps de transformation.

Je crois qu'il y a un pb de vocabulaire

Générer un xslt coté serveur cela veut dire : creer dynamiquement des feuilles xslt soient par dom , soit par d'autre xslt
Je ne pense pas que ce soit ce que tu veuilles dire ?

Ce que grandfather voulait dire c'est qu'on creer facilement des feuilles generiques qui se comportent differemment suivant les paramètres passés.
Le fonctionnement,pour la partie xslt, est le même que coté client , il n'y a que les syntaxe d'appel qui change.
Couplé avec les xmlhttprequest dit d' "AJAX" cela laisse une bonne souplesse

[SONY30]

Je crois qu'il y a un pb de vocabulaire

Certainement, je dois me mélanger les pinceaux

Générer un xslt coté serveur cela veut dire : creer dynamiquement des feuilles xslt soient par dom , soit par d'autre xslt
Je ne pense pas que ce soit ce que tu veuilles dire ?

Admettons que l'utilisateur pose un count() sur le paramètrage d'un attribut, je suis bien obligé de générer dynamiquement le XSL.

Ce que grandfather voulait dire c'est qu'on creer facilement des feuilles generiques qui se comportent differemment suivant les paramètres passés.
Le fonctionnement,pour la partie xslt, est le même que coté client , il n'y a que les syntaxe d'appel qui change.
Couplé avec les xmlhttprequest dit d' "AJAX" cela laisse une bonne souplesse

On est bien d'accord que l'utilisation de ces "technos" là (AJAX), diffèrent selon les navigateurs, hormis peut être "sarissa" dont j'ai vaguement entendu parler ?

[Erwy]

Admettons que l'utilisateur pose un count() sur le paramètrage d'un attribut, je suis bien obligé de générer dynamiquement le XSL.

Je ne sais pas , je ne comprends même pas ou tu veux en venir
Par contre , comme grandfather , je suis un gros utilisateur de ces technos et parfois dans des cas tres complexes et je n'ai utilise qu'une fois une feuille xslt qui en fabriquent une autre et ce n'etait pas du traitement dynamique mais un xslt qui était tributaire d'une table dans une base celle-ci bougeant suffisamment rarement pour que le dynamique ne soit pas necessaire

On est bien d'accord que l'utilisation de ces "technos" là (AJAX), diffèrent selon les navigateurs, hormis peut être "sarissa" dont j'ai vaguement entendu parler ?

dans mes souvenirs , peu.
Il me semble que la seul difference entre IE et firefox soient la simple déclaration de l'objet (qui peut se faire sur un test) mainteant faut voir la multiplicité de la cible

[SONY30]

Je vais repartir depuis le début pour expliquer (l'obligation ?) d'avoir une feuille XSL dynamique.
Soit un utilisateur qui paramètre une recherche (en gros une requête avec des attributs et des critères). Je suis capable de générer un fichier XML résultat du sytle

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="file-xsl.xsl"?>
<root>
<mere id="0001">
<reference>MERE0001</reference>
<nom>DUPOND</nom>
<pnom>Georgette</pnom>
<telephone>04-04-04-04-04</telephone>
<enfant id="1">
<nom>DUPOND</nom>
<pnom>Pierre</pnom>
<age>1</age>
</enfant>
<enfant id="2">
<nom>DUPOND</nom>
<pnom>Paul</pnom>
<age>2</age>
</enfant>
</mere>
<mere id="0002">
<reference>MERE0002</reference>
<nom>DUPONT</nom>
<pnom>Maryse</pnom>
<telephone>04-04-04-04-04</telephone>
</mere>
<mere id="0003">
<reference>MERE0003</reference>
<nom>DURAND</nom>
<pnom>Maryse</pnom>
<telephone>04-04-04-04-04</telephone>
<enfant id="1">
<nom>DURAND</nom>
<pnom>Pierre</pnom>
<age>1</age>
</enfant>
</mere>

...

</root>

Ce résultat là j'aimerais le présenter sous la forme d'un tableau HTML du style
<tr>
<td> Les X TD pour les titres des colonnes triables </td>
</tr>
<tr>
<td> Par mère les X informations de la mère </td>
</tr>

Sur cette page là, l'utilisateur pourra :
- Trier les informations par colonne
- Gérer le Multi page (Afficher les 10 premières mères, puis les 10 autres, etc...)
- Gérer des filtres sur les colonnes..
- Cliquer sur la mère ou sur les enfants pour afficher leur détail...

C'est pour certains de ces besoins là, que ma XSL ne peut être statique mais générée à la volée de la même manière que mon XML.
Je suis d'accord que pour les tris, le multi page, voire les filtres, cela peut être géré par le passage de paramètres à ma XSL, mais pour les informations cliquables (présentant un href) pour les entêtes de colonne... ces informations là ne sont pas déductibles de mon XML...

En fait c'est peut être à moi, de mettre le maximum d'informations dans mon XML, pour que le XSL soit complétement autonome et donc plus regénéré systématiquement.

[Erwy]

- Cliquer sur la mère ou sur les enfants pour afficher leur détail...
....mais pour les informations cliquables (présentant un href) pour les entêtes de colonne... ces informations là ne sont pas déductibles de mon XML...

je vois vraiment pas le pb , ces infos sont dans ton xml d'apres ce que je lis.
Soit tu les caches dans des div et tu affiches au fur et a mesure soit tu fais un autre xslt auquel tu passe comme parametre la balise dont tu veux le detail, soit tu as plusieur mode dans un seul xslt et tu change d'affichage suivant le paramètre.
Si ce sont d'autres infos qui ne sont pas dans ce xml qui posent pb alors de toute façon il faut aller chercher un autre xml, je ne vois pas en quoi generer un autre xslt sert