> Torsten Curdt wrote:
>
> > > > With the current design of cocoon2 it is not possible to
> have always a
> > > > clean error page.
> > > > The problem is that the components, e.g. the content
> aggregation write
> > > > directly to the output stream. If some components have
> written something
> > > > and an error occurs it is forbidden by the servlet engine to do
> > > a redirect
> > > > and the output stream cannot be reset.
> > > >
> > > > I wanted to address this problem by the concept of an
> > > intermediate output
> > > > stream, but there is currently no consense found.
> > >
> > > consensus seemed to be that an intermediate output stream was
> fine as long
> > > as we could configure it on or off on a per-sitemap or
> per-pipeline basis.
> > > that was my impression anyway. does anyone disagree with this?
> > >
> > I do not totally disagree, but I don't like the configuration
> part of it.
> > When you design your site/create the sitemap you don't want to think
> > about how the pipelines should be handled: if the output stream
>
> Well, I think the sitemap designer has to think about stuff like
> this anyway... if the pipeline is internal only or not... stuff
> like that.
>
Yes, this is right, but internal or not is more a "security" problem,
that means, you have to decide which content is available to the
world.
But deciding which "streaming method" is used is a pure technical
decision which no sitemap editor wants to deal with. Usually he
doesn't know about such things and does not have to care about them.
> > should be directly written or "cached" and then written.
>
> I think we will loose a lot of a speed impression if we
> go back to the C1 behavior!
>
> > And the other think is, if the stream is directly written to the
> > output stream, the error handling is not working properly as
> > the result can consist of the first part of the real response followed
> > by the error information. This is really bad.
>
> Well, that is for sure true! But since I hope people don't see
> it too often I would go for the performance ;)
Yes, believe me or not, but I thought something like that, too.
I thought that perhaps this could be configurable not on the
pipeline level but in general, like caching or not (in the cocoon.xconf).
For production sites you would use the performance solution
and for developing the slow one with the nice error messages.
Carsten
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
