cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!
Date Mon, 10 Nov 2003 19:58:25 GMT
Sylvain Wallez wrote:

>>> Congrats for your project. But I really think this unspecified 
>>> behaviour you're using is not the good way to go. So let's keep it 
>>> as is in the upcoming 2.1.3 and forbid it in 2.1.4.
>> Why forbid it?  I see no reason to elminate such a useful feature, 
>> unspecified or otherwise.
> There's been a discussion about this, and we agreed on the fact that 
> he semantics of <map:call function> and <map:call> continuation 
> implied that it _must_ redirect somewhere using sendPage, 
> sendPageAndWait or redirectTo.
> The semantics you would like is the one of an action. I proposed to 
> add a "flowscript action" that would share function and global 
> variable scopes with the flowscript but have the appropriate contract 
> of returning a Map of values to the sitemap.
> So the flowscript call semantics will be strengthened in the 2.1.4 to 
> avoid abuses of this unspecified behaviour. And the fact that you 
> already rely on this behaviour shows that we must correct things quickly.
> If it was only me, we would forbid it ASAP for the 2.1.3 release. What 
> do others think?

My interpretation of the discussions and votes was that we:
   a) Do not allow nested sitemap components within <map:call>
   b) Do not allow returning Map as result of flow script invokation

These two pretty much rule out flowscript actions, but:
   c) Allow flowscript to return empty response by the way of invoking 

Which solves empty response issue for webdav etc. And the last:
   d) No other decision was made

Which means that if you do not call sendPage* and do not call 
sendStatus, sitemap will continue execution. Did I miss something?


View raw message