cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Attar <...@tireme.fr>
Subject Re: Erreur "<map:call function> did not send a response"
Date Wed, 21 Sep 2005 09:07:26 GMT

>>
>>       // 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".


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

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.

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.
- mieux mettre en avant cette limitation dans la doc XSLT-cocoon.

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.

Dans tous les cas, merci pour vos explications.

Pierre




Pierre Attar (mailto:pat@tireme.fr)
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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message