From: matthieu (mat.m@netcourrier.com)
Date: 04/12/2002 - 13:34
merci pour votre réponse très complète.
>Bonjour,
>
>On Wed, 2002-12-04 at 13:36, matthieu wrote:
> >
> > Bonjour,
> >
> > Je suis nouveau sur cette liste et je vais sans doute aborder un sujet
> deja
> > traité antérieurement sur cette liste.
> >
> > Une première question qui s'adresse surtout à Eric van der Vlist :
> > Quelle est la solution employée sur XMLfr.org pour transformer les données
> > stockées en base en fichiers XML,
> > puis pour transformer le XML en pages (X)HTML ? java, php... ?
> > Pourriez-vous décrire schématiquement cet aspect du fonctionnement du
> site ?
>
>XMLfr utilise un environement Java. Le serveur de servlets est JServ et
>le servlet utilise le processeur XSLT XT en passant en paramètre une
>représentation XML de son environnement, cf:
>
>http://4xt.org/downloads/examples/xslservlet/result-tree/
>
>Toutes les pages sont générées par une transformation XSLT unique (à
>part les archives de mail et les résultats de recherche htdig qui
>utilisent des technologies totalement différentes) utilisant la
>technique que j'ai décrit sous le nom de "feuilles de style sans style":
>
>http://xmlfr.org/documentations/articles/001214-0001
>
>Les pages de l'index sont les seules à accéder à une base de données
>(PostgreSQL). Les requètes SQL sont constituées en XSLT à partir de
>l'environnement du servlet passé à la transformation en paramètre. Elles
>sont envoyées à la base de données et les résultats récupérés sous forme
>d'évènements SAX au moyen d'un classe Java très simple développée "sur
>mesure" et utilisant JDBC. Le mécanisme utilisé par cet index est décrit
>dans:
>
>http://xmlfr.org/documentations/articles/010312-0001
>
>Enfin la page de sondage est implémentée (toujours en XSLT) en utilisant
>un service web "REST":
>
>http://xmlfr.org/documentations/articles/021115-0002
>
>Les mêmes fonctionnalités auraient pu être implémentées en utilisant un
>framework tel que Cocoon. Je ne l'ai pas fait pour trois raisons:
>
>- Je souhaitais "mettre les mains dans le cambouis" et développer un
>maximum de composants pour évaluer la complexité des technologies XML de
>base.
>- Lorsque j'ai lancé XMLfr en début 2000, Cocoon était loin d'être
>stabilisé et les premiers essais montraient des temps de l'ordre de
>trois secondes pour la transformation d'une page! A titre de
>comparaison, la plupart des pages de XMLfr sont constituées en moins de
>100 ms.
>- L'approche de Cocoon est une approche que je qualifierais de "push" où
>les pages sont constituées d'après une modélisation du site et des
>"pipes" de transformations et il me semble plus naturel d'adopter une
>logique inverse "pull" où l'on part d'un "layout" de page dans lequel on
>inclut des éléments.
>
> > D'autre part, pensez-vous (je m'adresse à tous) que les parseurs XML
> > intégreront à terme les navigateurs clients, ou bien nous dirigeons-nous
> > vers des solutions de transformation XML/XSLT installées coté serveur ?
>
>Les deux :-) .
>
>Tout d'abord, il faut remarquer que même si les navigateurs incluaient
>tous un parseur XML et un processeur XSLT, il n'y a pas d'API standard
>permettant de contrôler les transformations.
>
>C'est le cas aujourd'hui avec IE 6.x et Mozilla 1.x: les scripts
>développés avec IE 6 et permettant par exemple de définir des critères
>de tris en modifiant la transformation et en l'appliquant à nouveau
>utilisent des fonctions qui ne sont pas spécifiées dans le DOM et ne
>sont pas compatibles avec Mozilla.
>
>Ensuite, si l'on reprend un exemple comme une page de l'index de XMLfr,
>exécuter la transformation au niveau du client voudrait dire que l'on
>devrait accéder à la base de données (en direct ou par un service web) à
>partir du poste client, ce qui n'est pas nécessairement souhaitable.
>
>Même pour une page comme la page d'accueil qui inclut des informations
>extraites de 8 documents RSS différents, la consolidation de ses
>informations (dont seul un résumé est affiché) au niveau du poste client
>génèrerait un trafic très supérieur au volume de la page après
>transformation.
>
>Je pense donc que l'architecture "idéale" est une double transformation:
>transformation sur le serveur pour préparer les informations et
>transformation sur le client pour peaufiner la présentation de manière
>facilement personalisable.
>
>Cordialement,
>
>Eric van der Vlist
--
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)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:06 UTC
webmaster@xmlfr.org
|
