Sylvain,
Merci pour ta réponse et pour la bonne nouvelle
quant aux facilités de debugging.
Ne suis pas sûr de tout comprendre sur
l'utilisation de document(). En gros, en 2.1.7,
les limitations existent-elles toujours ? Sont-elles corrigées en 2.1.8 ?
La question que je me pose est : est-il opportun
de tout réécrire dans mon code avec des
map:aggregate comme le propose le document cocoon
en référence [1] ou bien tout va-t-il se
normaliser et dans ce cas on peut continuer à contourner le problème ?
Si tu as plus d'informations ... welcome !
Pierre
[1] http://cocoon.apache.org/2.0/faq/faq-xslt.html#faq-6
At 11:22 21/09/2005, you wrote:
Pierre Attar wrote:
// since the result is dumped to the
filesystem we need to send smth. to the browser
// to make it happy. So let's send
just a usual .txt file with OK message
cocoon.sendPage("c:\\temp\\yes.txt",null) ;
ça ne me semble pas correct, un sendPage est
utilisé pour envoyer des données produites par un pipeline.
En fait, ca fonctionne plutôt bien et le
sendPage se transforme en une sorte de "reader".
Ca marche vraiment? Parce qu'en interne,
cocoon.sendPage("toto") fait un redirect sur
"cocoon:/toto", et crée donc une nouvelle
requête qui doit être résolue par la sitemap.
Oui, c'est bien comme cela que ca marche.
} catch( ex ) {
cocoon.log.error(ex);
// Smth. went wrong. Sending a error.txt file to the browser
//cocoon.sendPage("error.txt", null);
A mon avis, c'est par ici que l'on passe car
cocoon.sendPage("c:\\temp\\yes.txt",null)
; doit renvoyer une exception. Ainsi, on se
retrouve dans ce catch ou aucune donnée n'est
renvoyée (pas de sendPage) d'ou l'exception.
Oui, c'est exactement cela qui se passait.
Merci pour le conseil, des fois on a le nez
dans le guidon et on ne voit pas plus loin que le bout de son nez.
En fait, il fallait comprendre où sont les
message de debug de flowscript et tout devenait plus lumineux.
Au passage, la vraie erreur était dans mon XSLT
qui utilisait des document() avec des path qui
n'étaient pas ré-interprétés par cocoon.
J'ai bien compris, en lisant
http://cocoon.apache.org/2.0/faq/faq-xslt.html#faq-6
, que pour les concepteurs de cocoon, il ne
fallait pas utiliser la fonction document() de XSLT.
Attention, c'est la doc de la version 2.0 qui
est bien ancienne. Ca a été un sujet controversé
(les partisans du "l'aggrégation doit passer par
Cocoon" contre les "c'est bien pratique et
apporte les protocoles Cocoon au standard").
Au final donc, document() utilise bel et bien
les protocoles Cocoon. Attention toutefois :
conformément à la spécification XSLT, les
chemins relatifs sont interprétés relativement à l'emplacement de la XSLT.
Ca me gène quand même un peu car ca fait trop
une position dictatoriale de type :
"j'interprète ce qui me parait bon ou pas dans
un standard" ! Ca me gène d'autant plus que
XSLT est quand même le coeur du métier de
cocoon et que se permettre de ne pas
implémenter le standard coeur de métier peut
permettre des dérivations de ce type un peu partout ailleurs.
Je trouve vraiment que l'on souffre beaucoup du
marketing d'éditeurs de logiciels commerciaux
connus qui disent "oui je fais du XML mais
finalement, à ma sauce" pour reproduite la même chose ici.
Houla :-)
Dans tous les cas, si cocoon garde cette position, ca vaudrait le coup de :
- mieux "catcher" les erreurs XALAN liées à
cette utilisation car c'est fragile et un
développeur XSLT fait, a priori, ce que le
standard XSLT défini car c'est ce qu'il
connait, de façon indépendante des outils.
C'est fait dans la version courante (dans
subversion) et arrivera avec la 2.1.8 prévue pour octobre (voir aussi [1]).
- mieux mettre en avant cette limitation dans la doc XSLT-cocoon.
Elle n'existe plus !
Voilà donc un mail de quelqu'un un peu énervé
par le fait d'avoir cherché si longtemps une
erreur qui est liée au non respect des
standards. C'est pas si grave, cocoon
continuera à m'intéresser, vraiment, dans mes projets.
Bon, ben j'espère que cette réponse va te réconcilier avec Cocoon :-)
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/000210.html
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
Pierre Attar (mailto:[EMAIL PROTECTED])
Consultant en informatique documentaire XML
Consultant in Structured Document engineering
Tirème SARL (http://www.tireme.fr)
Projet "Mutualiser l'effort de montée en compétences sur XML"
http://www.mutu-xml.org/index.html
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
