Cliquez ici.
Cliquez ici.
Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.

 
Cliquez ici.

dev@xmlfr.org : liste de discussion des développeurs du site XMLfr

[dev@xmlfr.org] Re: XMLfr et Lucene : phase 2bis - tests avec Orbeon Presentation Server

[dev@xmlfr.org] Re: XMLfr et Lucene : phase 2bis - tests avec Orbeon Presentation Server

Auteur: Erik Bruchez <erik@bruchez.org>
Date: 29/09/2004 - 00:43

Sylvain Wallez wrote:

> J'ai lu la doc de Orbeon Presentation Server (OPS?), et ce qui me manque
> vraiment (outre le flowscript), c'est la notion de serializer,
> indépendant du support de sortie. D'après ce que j'ai compris, un
> serializer OPS est un processor sans outputs. Le problème est qu'il
> définit non seulement *comment* le document XML est sérialisé, mais
> aussi *où* on l'envoie (fichier, réponse http, etc).
>
> A mon sens, ces notions doivent être séparées. C'est le cas dans Cocoon
> et c'est ce qui permet de prendre la sortie d'une URL "cocoon:" pour en
> faire ce que bon nous semble.

Pour information: ces discussions sur la serialisation, ainsi qu'une
requete dans orbeon-user pour supporter des attachements avec l'email
processor, nous a conduit a considerer un revision de notre
architecture de serialiseurs qui fournisse une meilleure separation
entre:

o le format serialise (XML, HTML, JPEG, PDF, etc.)
o le support de sortie (HTTP, fichier, URL, etc.)

Une solution elegante consisterait a transformer legerement les
serialiseurs existants. Par exemple, le PDF serialiser ecrit par
defaut dans HTTP (enfin, ServletResponse). On convient que c'est une
limitation. Le processeur est modifie pour supporter une sortie
(optionelle pour backward compatibility?). Cette sortie genere en SAX
du Base64. Les autres serialiseurs en font autant.

On cree enfin de vrais serialiseurs (au sens XPL), dont la seule
fonction est de lire le stream SAX et d'ecrire dans le support
considere. On atteint la separation of concerns ci-dessous sans
utiliser d'URLs.

Tous les outils pour realiser ce changement sont deja presents dans le
code, cela pourrait donc etre rapidement implemente.

-Erik

--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de 
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant 
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Received on Wed Sep 29 02:44:19 2004

Archive générée par hypermail 2.1.8 le 04/10/2004 - 20:25 UTC

webmaster@xmlfr.org

 

dev@xmlfr.org

Liste de discussion de la communauté des développeurs de XMLfr.

Cette liste publique est dédiée aux discussions concernant la conception et le développement technique du site XMLfr.



Cliquez ici.
Cliquez ici.

Devenez rédacteur <XML>fr et contribuez au développement du xml francophone !
Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org