Carsten Ziegeler pisze: > Hmm, no, I don't think so :( > I think most of the relevant code is in the SitemapHelper class.
Thanks, I'll have a look. >> Is the context really changed for each sax events? I thought that cocoon: >> protocol creates some kind >> of derived environment for each cocoon: call and this way (some) separation >> is assured. >> >> Can you point me to relevant place? > It's in the SitemapSource. There is a special sax event wrapper which is > placed around the receiving sax handler: > EnvironmentHelper.createEnvironmentAwareConsumer(consumer) > So for each sax event the environment is changed back and forth. You are right. Argh, SitemapSource is even more complicated than I thought... >> I agree. The servlet: protocol does buffering but it does something more: it >> serializes and parsers >> XML each time servlet request is made. This really affects performance and >> must be changed but it's >> not that hard and the change would limited to only cocoon-servlet-* modules. > Yepp, I think we should support the extensions of the > HttpServletResponse which we discussed > a long time ago and which can be found in the processor module of our > whiteboard. > The buffering could be a recording of sax events with the sax buffer. I was discussing very similar idea with Leszek at GT and he expressed interest in implementing such behaviour for respone/request classes used by servlet protocol. Leszek, do you still plan to implement this in a foresable future? When it comes to the request being SAX aware there is a small problem. There was a common agreement that we should implement fall-back mechanism in case that called servlet does not support SAX-aware request/response combo. The fall-back mechanism would work the way as reqest/reponse classes work now so the incoming SAX stream is serialized into request's body and produced SAX stream is serialized to response's body. However, at the same time we agreed that we would like to forward request data (including parameters, uploaded files) from original request. Then there is a clash between data coming from SAX events and uploaded files that must be included in the same request body. I don't know any good solution for this problem apart from encoding serialized SAX stream as another uploaded file. Any ideas on this? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
