cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!
Date Thu, 06 Nov 2003 10:17:24 GMT
 

> 
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: woensdag 5 november 2003 21:23
> To: dev@cocoon.apache.org
> 
> (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.
> 

If they were not meant to be perhaps the need for such a construct is
now emerging?

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

But the action construct has the flaw that its flow-like behavior is now
superseeded by the flow proper. I get the attraction for a flow call
statement with children but are you sure you need a non-final one? Can
you give an example?

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

I'd prefer a different statement to avoid the action behavior of
continuing after the act statement.

> Think of this action as a "secondary controller" in a MVC 
> model (they fine-tune the view but don't change it 
> radically), 

If you allow non-final behavior, the view could radically change:

<map:match>
  <map:act>
    <map:gen />
    <map:ser />
  </map:act>
  <map:read />
</map:match>


Regards, Unico

> 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