Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Looking at the AbstractProcessingPipeline the getMimeType method of the
serializer is called from the setMimeTypeForSerializer method that in
turn is called in the beginning of the processXMLPipeline method
*before* the generator.generate() method that lead to the actual
execution of the serializer. I might be missing something, but AFAICS
the call of the setMimeTypeForSerializer method call could be moved to
*after* the generator.generate call without changing the result at all.
This will work only if output stream of Http response is buffered so nothing is sent to the browser before setMimeTypeForSerializer is
called. Is it always the case?
That would make the servlet-service-impl dependent on
cocoon-pipeline-api, which I wouldn't like at all. The idea with the
servlet service stuff is that it should be independent of the rest of
Cocoon.
Yes, I agree with idea and would like to violate its independence and that's
why I seek for other solution.
First I wonder why the forms frame work depend on Environment specific
things and not just what is present in the standard http request object.
After sleeping with a problem in mind I guess that situation is not such dramatic and you can be probably right that passing only request
data is enough.
However, if pass for example uploaded files sent by browser we need to think
about:
1. Passing an XML stream serialized and encoded in request body, along with
data sent by browser
2. Avoiding reparsing again and again input data sent by browser
I really see both points quite troublesome. For first one, I guess we would have to encoded that stream as yet another file the same way as
browser encodes multiple uploads.
Any thoughts, hints?
But if we leave that for the moment I think that the best way to pass
information (e.g. request, response and maybe environment object) in the
call chain in an unintrusive way is by using a call stack. I implemented
a fairly generic call stack in o.a.c.callstack in the
cocoon-servlet-service module. It also provide a custom Springframework
call scope (see
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-custom
about custom scopes) that makes it possible to get the "current"
environment object through ordinary dependency injection.
The call stack o.a.c.environment.internal.EnvironmentStack in
cocoon-sitemap-impl is used internally in the sitemap for passing
environment info to e.g. subsitemaps and Cocoon calls. By refactoring it
so that it used the o.a.c.callstack stuff internally, we could have a
common callstack both for block calls and sitemap internal calls. Then
environment info and other servlet specific info could be passed in an
unintrusive way.
Certainly, this functionality would be useful but I fear that it would take me a lot of time to do it properly. Any chance that you will be
able to help in foresable future?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
