> Hi,
>
> I am currently thinking since some weeks of the following enhancement:
>
> Creating an intermediate output stream for the response and not directly
> writing to the output stream of the servlet engine (or the environment).
>
> This would solve the following problems:
> 1. The output stream can be reset at any time, making redirections
possible
> at every stage (although I personally don't like this, but there seems
> to be a great demand for it)
> 2. When the error pipeline is called due to any exception etc, the output
> stream should be reset as a new error generator starts producing new
> output. If accidentally something was already written to the output
> stream, you get a confusing response.
> 3. The special cocoon urls can currently not be used everywhere, e.g.
> inside a map:redirect-to statement. We could solve this by resetting
> the intermediate output stream and start on the server a new
> generation process without returning to the client.
If I get you right, this will enable RequestDispatcher.forward()/include()
like behavior in sitemap, right? That would be great. This will also enable
to use Cocoon as a controller servlet, e.g. with pure JSP pages (not from
JSPGenerator): some actions could be performed in the pipeline, say, request
data processing, etc. and the request could be forwarded to a JSP page to
view the data in a form, etc. In the current implementation it's possible
only with redirect, which is not my favourite way of flow control.
> 4. The content length of each response can be determined. This seems
> to be important for the pdf generation (see the corresponding thread
> on the user list).
>
> The only disadvante I see currently is some loss of performance.
>
> Comments? Critics? Suggestions? Wishes?
Just some thoughts about what can be the "minimal Cocoon" and "typical
Cocoon". Currently, I don't use any XSP, SVG, PDF, etc. in C2 - it's used
only as a screenflow controller servlet (like in Model - View - Controller
design pattern). The pages are in JSP (don't ask me why, I am not the author
of this design) and we need only to control their sequence. So, with forward
and include capabilities in sitemap the "minimal Cocoon" could be only the
servlet and engine, which are necessary for sitemap processing, without
anything else, including XSP. So, after installing the "minimal Cocoon" the
developer can add pipelines, matchers, actions, views, resources, which are
necessary for his application only.
"Typical Cocoon" could be a "typical" set of generators, transformers,
serializers and maybe selectors, which are used in most of the Cocoon based
applications.
And, at last, "full Cocoon" could be a full set of everything in Cocoon,
including samples.
Additionally, can be an option for installing 3rd party tools, like the
sitemap editor, or so.
Sorry, for a little off-topic comments.
>
>
> Carsten
>
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
