>
> -----Original Message-----
> From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
> Sent: woensdag 5 november 2003 14:29
> To: [EMAIL PROTECTED]
>
> Unico Hommes wrote:
> >
> >
> >
> >>-----Original Message-----
> >>From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
> >>Sent: woensdag 5 november 2003 14:02
> >>To: [EMAIL PROTECTED]
> >>
> >>Stefano Mazzocchi wrote:
> >>
> >>
> >>>>setStatus' friends the sendError brothers are also be
> eligible for
> >>>>FOM membership. But this change has a dependency on the
> discussion
> >>>>about bodyless responses since if you'd do a sendError
> from a flow
> >>>>script and then send a page afterwards this would result
> in errors.
> >>>
> >>>
> >>>I dislikde "sendError" because, in fact, HTTP does not have the
> >>>concept of errors, but only status codes and empty-payload
> >>
> >>responses.
> >>
> >>>In the future, it's entirely possible to have a 309 or
> >>
> >>equivalent that
> >>
> >>>is not an error, but has a empty-payload response. I would
> >>
> >>dislike to
> >>
> >>>call "sendError()" to send something that is not an error,
> >>
> >>feels hacky.
> >>
> >>>I think the optimal solution is:
> >>>
> >>> 1) add response.setStatus() in FOM
> >>> 2) allow the flowscript to terminate without calling
> >>
> >>sendPage* [thus
> >>
> >>>resulting in an empty payload]
> >>
> >>Sorry to jump in late, I'm probably lagging behind a few posts, but
> >>was the possibility of having *pipelines* send empty payload
> >>considered instead? This way flow will always have to
> sendPage(), but
> >>the result would be empty content anyway. With the added bonus of
> >>having the pipeline flexibility to, say, set headers.
> >>
> >
> >
> > But the function of a pipeline is specifically towards the
> production of
> > an xml response body. To have to set up all the components,
> execute the
> > pipeline and then fooling the pipeline to send its data to
> a null output
> > or refrain from pipeline execution altogether? In some
> scenarios that
> > may be necessary, for instance in the case of the http HEAD
> function.
> > The point is, you shouldn't have to, because there are a lot of
> > situations where its just unneccesary overhead. (for example all the
> > dummy responses in the davmap sitemap)
>
> I sure can see some use of this. In a few cases (think PUT) you might
> have XML input flowing through the pipeline (say you might want to
> transform it) yet you have to send an empty response: in this
> scenario
> using a pipeline looks like the best option to me.
Hmm, not to me. The way I have implemented PUT in the current davmap
differs from what you are suggesting.
Here I use two pipelines. One generates the request body:
<map:pipeline internal-only="true">
<map:match pattern="request/PUT">
<map:generate type="stream" />
<!-- <map:transform type="myfilter" /> -->
<map:serialize type="xml" />
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="PUT/**">
<map:call function="put">
<map:parameter name="input" value="cocoon:/request/PUT" />
<map:parameter name="output" value="{global:staging}{1}" />
</map:call>
</map:match>
</map:pipeline>
The flow uses essentially the internal only request body generating
pipeline in a processPipelineTo type of construct:
Function put(in,out) {
var s1 = resolver.resolve(in);
var s2 = resolver.resolve(out);
cocoon.processPipelineTo(in.inputStream, out.ouputStream);
cocoon.response.setStatus(201);
// have to do:
cocoon.sendPage("dummy",{});
// but really want to do this:
// return null;
}
> Also, I
> feel that the
> sitemap is core and flow, while being core, is somehow
> "piggybacked" on
> the sitemap. I tend to think, then, that deciding whether to
> send output
> or not should belong more to the sitemap than to the flow.
>
The sitemap is always in control, we are talking about changing the
sitemap semantics in that a <map:call function /> is extended so that it
can signal the sitemap to terminate processing the request. Maybe we
could add an attribute specifically allowing the function to not send a
page such as in <map:call function="blah" redirect="false" /> but I
think this will only complicate things because now what happens if the
function does do a redirect? And what if we want to do what Vadim
suggested:
<map:call function="login">
<map:generate />
<map:transform />
<map:serialize />
</map:call>
Function login() {
while(!loggedIn) {
sendPageAndWait("login");
loggedIn = ..
}
return {user:"user",message:"message"};
}
-- Unico
> Ciao,
>
> --
> Gianugo Rabellino
> Pro-netics s.r.l. - http://www.pro-netics.com
> Orixo, the XML business alliance - http://www.orixo.com
> (Now blogging at: http://blogs.cocoondev.org/gianugo/)
>
>
>
