Grzegorz Kossakowski skrev:
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?
As Vadim notes, it is not allways the case.
So I'm afraid that we are back at your original proposal, which as Vadim
noted has some other problems :/
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
This is something we have discussed before isn't it? The main idea is to
extend the request and response object with some sax handling APIs.
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?
For the multi part mime parsing that is used for e.g. uploads, the main
problem is the way that this typically is handled in servlet based
webapps. I.e. that all multi part mimes are handled already in a filter
that is used before the servlet. In Cocoon it would be more natural to
do multi part mime handling in the sitemap so that different things can
be done for different URLs. Also the mime type handling could be
deferred to the actual servlet service that is going to use it instead
of doing it in front of the main servlet.
One could also consider havíng servlet service specific filter chains.
This could be implemented with Spring interceptors that are added to a
servlet service and intercepts the servlet calls.
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?
That is my intention.
/Daniel
