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.
} 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]
