>
> -----Original Message-----
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: woensdag 5 november 2003 21:23
> To: [EMAIL PROTECTED]
>
> (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
>
>
>
>
