On Nov 16, 2005, at 14:37, Herve AGNOUX wrote:
> Le Mercredi 16 Novembre 2005 10:14, Robin Berjon a écrit :
>> Aller effectuer les transformations avec du DOM ça tient la route
>> tant qu'il s'agit d'aller chercher quelques valeurs ici et là, mais
>> dès qu'il faut faire une transformation de structure complète (comme
>> ça a souvent été le cas dans mon expérience quand il s'agit de
>> produire des sites webs) c'est beaucoup, beaucoup plus fastidieux que
>> XSLT. Aussi, il devient rapidement difficile de "sous-classer" un
>> template utilisant DOM pour modifier légèrement une partie du site,
>> alors que c'est trivial à faire en XSLT.
>
> Je ne comprends pas. Lorsque on utilise une feuille JSP, elle n'a
> déjà pas du
> tout la même structure que le XML qu'elle affiche, et elle ne
> génère pas du
> tout la même structure ; la transformation de structure est faite
> de base ;
> forcément, elle "n'a plus que" aller chercher quelques valeurs ici
> et là...
> c'est mieux, non ??
Ca ne marche que si la structure finale ne dépend que très peu de la
structure d'entrée. Si par exemple on a un JSP qui contient
pratiquement toute une page XHTML et qu'on ne va que chercher un nom,
un email, et un commentaire pour remplir le XHTML ça roule (mais pour
quelque chose d'aussi simple, /bin/sh ferait l'affaire). Si par
contre on passe à quelque chose de plus complexe comme la conversion
de données géographiques en SVG, ou même ne serait-ce que la
génération d'une barre de navigation de profondeur arbitraire, ça
devient tout de suite fastidieux en DOM alors que ça reste évident en
XSLT.
>> XSLT dispose de peu de capacités dynamiques, JSP et PHP sont atroces
>> pour effectuer du formattage. La paire est bien faite je trouve.
>
> Là non plus je ne comprends pas !? PHP atroce pour effectuer du
> formatage ?...
> cela me surprend un petit peu. Quand à JSP il me semble que cela
> fonctionne
> très bien, au contraire ?!
Ca fontionne oui, mais à de trop rares exceptions près, on se
retrouve avec un doux mélange de logique applicative, d'appels vers
des bases de données, et de code HTML faisant tantôt de la
structuration, tantôt de l'affichage. Bref, de la soupe que je trouve
désagréable à gérer, surtout au long terme ou pour des projets un peu
larges, demandant des changements de présentation importants. D'où
l'idée de séparer au plus possible la génération du contenu (XML) de
sa transformation (XSLT) vers des formats de sortie (XHTML, SVG...).
Mais bon, ce n'est que mon expérience personnelle, si tu es très
content de ce que tu utilise surtout ne change rien :)
> (ou alors vous employez "atroce" dans le sens de super, décoiffant,
> hyper
> efficace, comme j'ai l'impression qu'il s'emploie quelques fois
> chez les
> jeunes branchés, un peu comme "ça déchire"... excusez-moi mais je suis
> quelques fois paumé dans les différents registres de langage...).
Non, par atroce j'entends bel et bien "(1) Qui est d'une grande
cruauté" ou encore "(2) Excessif en mal", quoique probablement plus
proche de "(3) Utilisé familièrement et par exagération" :) J'aime
bien l'étymologie: du grec atrox, littéralement "ce qui ne se mange
pas", non comestible.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Received on Wed Nov 16 14:53:36 2005
