Discussion :

[garthos]

je voudrais savoir si existe quelque chose de plus performant que les transformation XSL ?
Quel sont les méthodes pour faire le rendu html utilisé à l'heure actuel ?

merci

[sheura]

Mon cher ami à mon humble avis XSLT est la meilleur des solutions pour faire du rendu de manière générale (faut dire aussi que je n'en connais pa d'autres mais bon ....). J'ai eu à l'utiliser avec PHP et JAVA, et je peux t'assurer que j'ai toujours était satisfait. du résultat. Maintenant ... chacun son point de vue.

[Laurent.B]

Ta question manque un peu de clareté...
Quel est ton objectif?

Si tu veux faire du XSL tu peux le faire au sein des JSP, à l'aide de JSTL par exemple (ce sont des tags) .

Avec les JSP on génère sans effort du HTML, XML, WML, XSL et tous types de fichiers s'il on veut, alors perso, je ne vois pas ce que tu veux dire.

[sheura]

Non je parle par exemple de générer une centaine de pages dynamiquement à partir d'une seule feuille XSL

[garthos]

bon alors je précise que je ne suis pas débutant ! tout ce que vous dite je le sais déjà !
ma question était d'ordre professionnel
le truc c'est qu'au taf on envisage de faire du refactoring sur nos webapps (je précise que ce sont des services pour le Wap, donc on génère du WML ou du cHTML ou de l'OML ou du PML)
à l'heure actuel nos webapps utilise donc des jsp (avec jstl, de l'xml, de l'xslt ....)
ce sont de petites webapps (ce qui est normal pour du wap) et donc nous avons environ 120 webapps sur notre serveur de prod qui commence à lutter

et donc je voulais savoir si il existe des solutions satisfaisante pour remplacer les transformations XSL ? car les transformations sont gourmande pour ce qu'elle sont.

je me demandais si CSS que je ne connais pas du tout, peu remplacer XSL ou si ça vient plus en complémant ?

[sheura]

Ouh la la
Tu as même citer des languages dont je n'ai jamais entendu parler mais bon... Css effectivement viens en complément à XSL pou rendu et c'est vrai que la transformation est gourmande en ressource seulement maintenant les clients sont de plus en plus riche, alors je me dis que plutôt que de ce faire coté serveur la tranformation peu être faite coté client (par exmple pour ce qui est de la transformation html). Je ne sais pas maintenant si pour les autres (wml, cHTML, ....) cela reste valable (à voir). Mais en gros l'idée est de déplacer une partie de la transformation coté client.

[garthos]

je comprend pas trop comment tu peu déplacer les traitement vu que je travail avec des bean qui eux meme travail avec une BDD, là je vois pas trop !
tu peu m'en dire plus ?

[sheura]

ben imagine que tu génère du xml avec tes beans là, au xml généré tu peux associer une feuille xsl et envoyer le tout au navigateur du client pour qu'il l'interprète et le transforme.

[sheura]

En fait tu n'enverras plus une page toute prete au client mais partiellement prete ce qui fait que ce sera à lui de faire la transformation avec le flux xml et la feuille xsl qui tu lui aura precisée.

[garthos]

mais c'est ce que je fais déjà et moi je veu plus de transformation xsl
mais la transformation elle se fait coté serveur quand je fais mon <x:transform ......
et c'est lourd en ressource les transformations

[sheura]

Je sais et je t'ai bien compris seulement moi je parle d'un truc du genre

Code :

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

1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="mafeuill.xsl"?>
<BEAN>
XXXXXX
</BEAN>

et ce sera tout ce flux que tu enverras au client comme ça c lui qui fera la transformation avec la feuille. C'est un peu comme avec html et css

[BizuR]

Je confirme les propos de Sheura, il est possible d'éviter le traitement de la transformation coté serveur en demandant au client d'utiliser une feuille XSL et de transformer tes flux que tu envoies en XML, en HTML, XHTML and cie...

Pour ce qui est des CSS, ils sont en effet complémentaires et fonctionnent de la même manière que la transformation XSL coté client... ainsi, en combinant XSL et CSS coté client, tu aboutiras à deux résultats :
- traitements coté serveur amoindris puisque ces derniers n'auront plus lieu (uniquement génération XML si ces derniers n'existent pas déjà)
- traitements moins lourd coté client puisque la feuille générée par XSL sera moins lourde dans la mesure où tu auras dissocié contenu et mise en page.
- tu risques par contre d'alourdir un petit peu le nombre de fichiers transférés a partir du serveur puisqu'il faudra aller chercher 3 fichiers au lieu d'un seul. (maintenant, ce que je ne sais pas, c'est si le navigateur conserve les CSS et XSL en cache ou bien si il les redemande à chaque fois ... j'espère sincérement que le cache sert ici )

Je ne sais pas ici ce qui sera le plus avantageux, mais j'ose penser que la solution CSS/XSL à transformer coté client sera plus acceptable pour le serveur.

Sinon, pour le detail (mm si tu n'es pas débutant), CSS permet surtout d'appliquer une mise en page à des éléments de ta page HTML, il permet de redéfinir l'ensemble des composants (même les objets de formulaire par exemple), possède un éventail de mise en page plus grand que HTML , offre une meilleure lisibilité des pages web (du code source), une meilleure maintenance, etc...

[garthos]

et vous auriez des lien à me filer sur cette maniere de faire ?
sinon c'est compatible avec n'importe qu'elle navigateur ?

[ericw78]

Si tu laisses le client transformer tes xml-xsl, tu risque justement de heurter à des sacrés pbs de compatibilités avec les navigateurs !!!

Code :

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

Le truc c'est qu'au taf on envisage de faire du refactoring sur nos webapps (je précise que ce sont des services pour le Wap, donc on génère du WML ou du cHTML ou de l'OML ou du PML)

Quand tu parles de Wap, à quels navigateurs penses-tu ?

[garthos]

ba justement y en a pas mal c'est suivant les téléphone et leur OS y an à 4 ou 5 principaux dont SymbianOS, PalmOS 5.4, windows mobile ....
donc je sais pas si c'est possible .

[Laurent.B]

A mon avis, il faut laisser tomber l'idée de faire faire le boulot aux navigateurs des terminaux mobiles. Perso, je ne connais que les terminaux de type téléphone mobile et je sais déjà qu'il y a des différences importantes dans les tailles de pages acceptées, ...etc, même si depuis le temps cela a dû faire des progrès.
Quant aux CSS c'est pire à mon avis.

Il faut se poser la question de savoir si effectivement la transformation XSL est si importante que cela. Car en effet elle permet, pour un même service mobile, de le décliner à moindre coût en divers formats tels que HTML, cHTML, WAP, PML, ...etc mais un service est-il réellement une même instance d'une webapp sur le serveur, avec un transformation différente selon l'opérateur? J'en doute car souvent il faut malgré tout faire des customs selon l'opérateur, notamment au niveau de la facturation. Du coup, la transformation XSL est rapide à adapter mais finalement on est obligé de dupliquer un service pour chacun des opérateurs afin d'éviter toute bizarrerie et tout mélange d'info impromptu. Dans ce cas, autant éviter le XSL, garder un business très modularisé et générer un format unique pour un service.
Je suis compréhensible?

[garthos]

oui c'est très compréhensible et éffectivement à l'heure actuelle on duplique les services pour les prob de facturation
mais bon la transformations c'est pratique je trouve et c'est facile à maintenir,
car en balançant direct des out.println dans des scriplet je trouve ça beaucoup trop bordélique ! j'aime bien séparé et je trouve ça logique de séparer le traitement de l'affichage.

donc un idée ? il faut que ça reste souple d'utilisation : l'objectif c'est performance et maintenance facile

[Laurent.B]

Ah non, il n'est pas question de mettre des out.println dans des scriptlets, le JSTL évite de faire cela justement, il n'est pas que bon à faire du XSL.

C'est un projet ambitieux de toute façon que de vouloir remanier 150 services, il faut prendre du recul...
Peut-être vous faut-il changer de version de server et de jdk si ce n'est déjà fait.

[garthos]

pour les out.println je parlais en fait en créant par exemple une servlet ayant le role de faire la transformation de mes donnée en html ou autre

[Laurent.B]

N'hésite pas à te pencher sur des frameworks comme Struts et Spring et je suis quasiment certain que ton histoire de XSLT ne tiendra plus. Ca change complètement de ce que tu dois connaître, il n'y pas de XML généré à la volée, de SQL dans les pages...etc.