On Wednesday, Nov 5, 2003, at 14:28 Europe/Rome, Gianugo Rabellino wrote:
Unico Hommes wrote:
-----Original Message-----But the function of a pipeline is specifically towards the production of
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 thatis not an error, but has a empty-payload response. I would
dislike tocall "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* [thusresulting 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.
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.
I agree that there are situations where it makes sense to go thru a pipeline even for potentially emtpy responses, but I also see tons of reasons to avoid going thru a pipeline again.
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.
hmmmm,
The sitemap is core in the fact that the flowscript function is still matched there... but deciding the output in case of an empty response is a concern of the "programmatical side of things", of the logic that "controls the flow" of hte application, not of the logic that drives the generation of the payload.
phisolophical issue, I agree, and hardly objective, but the more complex the webapp becomes (and webdavapps tend to be *very* complex from a flow perspective even for very simple cases) the more stuff should be done in the flow (and in java components directly called by the flow!) and less in the pipeline.
pipeline should deal with content, flow should deal with headers.
of course, your mileage may vary, but that's a potential design pattern that you might want to use to "measure" how you are writing your webdavapp....
... but this is such a undiscovered land that I might just be dead wrong.
but my gut feeling tells me that webdavapps will have a lot more flow than pipelines.
-- Stefano.
