Daniel Fagerstrom napisaƂ(a):
Alexander Klimetschek skrev:
Maybe a solution is to state the content type in the *calling* sitemap. I
cannot imagine a situation where your postable source could result in
different content types. You want control over that, because you probably
continue processing the returned data in the calling sitemap and there you cannot select between two versions. I can only think of XML processing (aka
text/xml) here anyway.

So this content type will be somehow injected into the postable source and
if the real content type is a different one, an exception is thrown.

WDYT? Are there any counter examples?
Don't know. The most important scenario for variable return content type is for content negotiation. If you POST something I guess that the input and output mime type would be the same in most cases.
But maybe there are some other cases.

Yes, there are. Take a look at pipeline handling Forms. Serializer is chose depending on request type (ajax/non-ajax). The idea was to hide that complexity in the service so one could just write:
<map:serialize type="servletService">
  <map:parameter name="service" value="servlet:forms:/renderForms"/>
</map:serialize>

and was fine. Obviously, if mime type had to be declared in calling sitemap one would have to deal with request types so there is less point to have a service at all :/

A somewhat hacky solution of the problem would be to let the ServletServiceSerializer get the object model from the environment. From that one can get the http request object and set the content type during serializer execution (e.g. in the startDocument() method) instead of during pipeline setup.

It will not work that way. Call is made in endDocument() not startDocument() 
method:
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/postable/components/ServletServiceSerializer.java
in this line:
IOUtils.copy(new StringReader(serializedXML), servletSource.getOutputStream());

--
Grzegorz Kossakowski

Reply via email to