cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!
Date Wed, 05 Nov 2003 20:23:00 GMT
(moving the discussion to @dev)

Unico Hommes wrote:

<snip/>

>>Mmmh... careful here : you're relying on a unspecified behaviour that allows a flow
script to not send a page. And we still have to decide if this allowed or not.
>>    
>>
>
>Better would be in this case to do in your saveToFile function:
>
>function saveToFile() {
>  
>  ...
>
>  cocoon.processPipelineTo("output.xml",{},fileInputStream);
>
>  // redirect to the page to display
>  cocoon.sendPage("success.html",{});
>}
>
>  
>

Exactly.

>>>From my point of view, this should not be allowed. 
>>    
>>
>
>I now believe this is true.
>  
>

Yep, with the help of an additional "no content" method on the response 
as discussed this afternoon.

>But ...
>  
>
>>And for this kind of purpose, I would better go for a "flowscript-action" that calls
a script function that returns parameters to the sitemap but which is not allowed to create
a continuation.
>>    
>>
>
>... why is that better than the above flow script? (I am not trying to be obstinate, I'm
just trying to understand. :-)
>  
>

Obstination shows the desire to understand ;-)

It's not better because of the actual JavaScript code, which would be 
more or less the same, but because of the sitemap semantics: <map:call 
function> and <map:call continuation> are meant to be final statements 
for the current sitemap execution and also are not meant to have some 
child statements whose executions could depend on the result of the call.

The sitemap statement that has these two semantics (not final with 
children) is <map:act>

That's why I'm suggesting an action of type "flowscript" that would call 
a function defined in the script files listed in <map:flow> and thus be 
able to share the session-global variables with <map:call> statements. 
Think of this action as a "secondary controller" in a MVC model (they 
fine-tune the view but don't change it radically), the <map:call> being 
the primary controller (it chooses the pipeline URI that fully defines 
the view).

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message