Transformer des données XML stockées provenant d'un serveur distinct

jbabadie · 27/11/2013 15:04:08

Bonjour,

Supposons que je souhaite créer (ou modifier) un service pour qu'il intègre des contenus stockés au format xml (+jpg pour image) sur un autre serveur.

1. est-ce envisageable facilement ?
2. comment s'assurer de la synchronisation des données lorsque le fichier xml distant est mis à jour ?

Raphaël Franchet · 27/11/2013 15:38:04

Bonjour,

c'est assez facile en effet : le plugin "Proxied Content" est fait pour vous.
Le contributeur saisit une URL du serveur distant et sélectionne une XSL fournie par le développeur.
Cette XSL doit sortir du HTML comme n'importe quel service Ametys. La partie <body> sera mise dans la zone sélectionnée par le contributeur.

Pour la synchronisation des données, Proxied Content est un service non cachable, ce qui signifie qu'à cache requête d'un visiteur, le serveur distant sera interrogé et la XSL repassée. Cela vous convient-il ?

jbabadie · 27/11/2013 16:01:00

Cela me convient très bien en tout cas pour la théorie c'est OK. Il ne me reste plus qu'à mettre ça en pratique
Merci

jbabadie · 06/05/2014 17:03:11

Petite question :
j'ai l'impression que les champs <![CDATA[]]> contenus dans le fichier XML sont totalement ignorés ?
Si c'est le cas, peut-on contourner la chose ?

Raphaël Franchet · 12/05/2014 11:08:19

Ce qu'il faut déterminer c'est qui supprime le CDATA.
Dans votre XSL vous pourriez transformer les CDATA en texte simple, pour voir s'ils arrivent jusqu'à votre navigateur.

jbabadie · 12/05/2014 12:16:24

Bonjour Raphaël,

le champ CDATA dans la XML contient du HTML de base (avec des liens).

On a testé la XSL en dehors du CMS et nous avons un rendu qui fonctionne bien.
Donc j'essaye d'adapter cette XSL pour qu'Ametys en veuille à son tour mais là j'ai l'intuition qu'il y a un "truc caché".

J'ai essayé moultes combinaisons pour transformer ce champ, mais il semble que le cms zappe directement la balise avant même d'essayer de parcourir son contenu. Nous n'avons même pas un message d'erreur ou une page blanche, c'est comme si le champ n'existait tout simplement pas.

Dans votre XSL vous pourriez transformer les CDATA en texte simple, pour voir s'ils arrivent jusqu'à votre navigateur.

J'ai bien essayé mais sans succès... si tu as une piste je suis preneur.

Voici l'appel qui fonctionne en dehors du CMS :

<xsl:value-of disable-output-escaping="yes" select="composante/details_composante/presentation" />

Raphaël Franchet · 13/05/2014 16:14:30

Il y a en effet un "truc".
La XSL sur laquelle vous travaillez donne en sortie du HTML qui vient en entrée d'une autre XSL : celle de la charte graphique qui place les zones.
Du coup le "disable-output-escaping" est anéanti par cela : il ne fonctionne que si c'est la toute dernière XSL.
En effet, "disable-output-escaping" est plus un hack qu'autre chose à la base.
Ensuite, si votre CDATA contient du HTML sous forme de texte, je ne vois de moyen de le convertir en VRAI xml sans écrire du JAVA

En fait, actuellement avec le plugin proxied-content le flux que vous avez en entrée est traité comme étant du HTML et du coup il "répare" les balises mal-formées pour en faire du XML valide. Peut-être est-ce lui qui détruit vos CDATA ?
Mais sinon, il y a donc après votre XSL une deuxième XSL de la skin. Peut-être est-ce elle qui détruit vos CDATA ?

C'est pour ça que vous pourriez "matcher" un CDATA et écrire "toto". Juste pour savoir si le CDATA a atteint votre XSL ou pas.

jbabadie · 16/05/2014 11:06:40

On a testé. Rien en sortie avec seulement du texte dans le CDATA.

Raphaël Franchet · 16/05/2014 11:23:35

Oui, ça ne doit pas changer grand chose. Le test auquel je pensais, était de matcher un CDATA et d'écrire du texte en dur sans CDATA en sortie

<![CDATA[test]]>
=>
<p>toto</p>

Ainsi on saura, si la XSL reçoit le CDATA ou pas en entrée.
Si elle le reçoit, le bug bient du cheminement des XSL, si elle ne le reçoit pas cela vient du JAVA qui n'est pas adapté à votre cas.

jbabadie · 25/06/2014 15:42:29

Donc ce n'est pas la XSL de la skin qui pose souci mais bien le JAVA qui n'est pas adapté à notre cas. :-(

Last edited by jbabadie (04/11/2014 11:31:35)

Raphaël Franchet · 30/06/2014 11:59:51

votre message a été tronqué

Forum Ametys

#1 27/11/2013 15:04:08

Transformer des données XML stockées provenant d'un serveur distinct

#2 27/11/2013 15:38:04

Re: Transformer des données XML stockées provenant d'un serveur distinct

#3 27/11/2013 16:01:00

Re: Transformer des données XML stockées provenant d'un serveur distinct

#4 06/05/2014 17:03:11

Re: Transformer des données XML stockées provenant d'un serveur distinct

#5 12/05/2014 11:08:19

Re: Transformer des données XML stockées provenant d'un serveur distinct

#6 12/05/2014 12:16:24

Re: Transformer des données XML stockées provenant d'un serveur distinct

#7 13/05/2014 16:14:30

Re: Transformer des données XML stockées provenant d'un serveur distinct

#8 16/05/2014 11:06:40

Re: Transformer des données XML stockées provenant d'un serveur distinct

#9 16/05/2014 11:23:35

Re: Transformer des données XML stockées provenant d'un serveur distinct

#10 25/06/2014 15:42:29

Re: Transformer des données XML stockées provenant d'un serveur distinct

#11 30/06/2014 11:59:51

Re: Transformer des données XML stockées provenant d'un serveur distinct

Board footer