Le vendredi 14 janvier 2005 à 17:41 +0100, nicolas.Duffillot@nxbp.fr a
écrit :
> Bonjour,
>
> Je souhaiterais savoir quelles sont les éventuelles différences majeures
> qui peuvent exister entre des traitements de fusion xml/xsl exécutés côté
> client ou côté serveur.
>
> Ma question est motivée par le constat suivant :
> En "client side", il est possible de passer des paramètres dans l'URL. Ces
> paramétres de type clef=valeur sont récupérés par du javascript et sont
> directement utilisable en tant que constantes (xsl:variable) afin de
> filtrer les éléments au moment des transformations. Ainsi, à partir d'un
> document unique, il est possible d'afficher dans le navigateur N résultats
> en fonction des valeurs prises par les variables.
En client side, les parametres ne sont pas passés dans l'url, mais
directement à l'appel de la transformation depuis le code javascript.
> En mode "server side", à juste titre préconisé dans la majorité des cas,
> est-il possible d'affecter des valeurs à des variables prédéfinies avant
> d'exécuter la transformation ? Le résultat décrit ci-dessus peut-il être
> obtenu de la même façon dans les 2 modes ? (1 doc + 1 xsl = N
> transformations ?)
Ici les parametres vont être passées dans l'url (ou dans un cookie, ou
dans le corps de la requete, enfin par un moyen ou part un autre mis à
dispo par HTTP). un script sur le serveur (php, perl, python, cgi, java
ou autre) va traiter la requete, décoder les parametres et les
transmettre à la feuille xslt pour la transformation. On a donc toujours
1 doc xml + un xsl (avec parametre => n transformations) -> un (x)html
Le critère de différence n'est pas sur la capacité à passer des
parametres au xslt, mais plutôt à la concentration de la charge de la
transformation sur le server (qui eut etre problematique en cas d'accès
très nombreux) vs. le support xslt par le navigateur (bien supporté par
mozilla 1.3, ie > 5.5, mais problématique pour les vieilles versions -
certaines sociétés imposent encore des netscape 4 en interne... - , les
gens sur macintosh...).
Donc tout dépend de l'environnement !
>
> Merci,
>
> N.D.
>
> L'integrite de ce message n'etant pas assuree sur internet, Natexis
> Banques Populaires ne peut etre tenu responsable de
> son contenu. Toute utilisation ou diffusion non autorisee est
> interdite. Si vous n'etes pas destinataire de ce message, merci de le
> detruire et d'avertir l'expediteur.
Ha tiens cette notice n'est elle pas en contradiction avec le fait que
les messages soient archivés et accessibles au public sur xmlfr.org ?
> The integrity of this message cannot be guaranteed
> on the Internet. Natexis Banques Populaires can not therefore be
> considered responsible for the contents.Any unauthorized use or dissemination is prohibited.
> If you are not the intended recipient of this message, then please delete it and
> notify the sender.
>
> --
> 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)
>
>
--
Stéphane Bonhomme -- Exselt Services
Formations, Conseil et Réalisations en Ingénierie Documentaire,
Technologies Web et Logiciels Libres
s.bonhomme@wanadoo.fr - http://www.exselt.com
04 76 17 09 40 / 06 88 57 27 08
--
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 Fri Jan 14 18:03:40 2005
