| Issue 129: | Exports Depend on HttpServletResponse | |
| 1 person starred this issue and may be notified of changes. | Back to list |
Currently, the exporters depend on the presence of an HttpServletResponse
to do their work. Portlet API 2.0 adds a ResourceResponse which is able to
set content types, headers, and serve binary content, but it is not in the
heirarchy of HttpServletResponse. It would be nice if there were an
interface ('WebResponse'?) to abstract out the details of the various
functionality that the exporters require.
This is not high priority because in the portlet environment there is a
workaround by simply dispatching to a servlet whose purpose is to handle
the rendering (Spring Portlet MVC does this to reuse the Spring view
technologies). I think that adding an interface is a better long term
solution though.
Jul 29, 2008
#1
extremec...@gmail.com
Jul 29, 2008
(No comment was entered for this change.)
Status:
Accepted
Jul 30, 2008
I think that the design you're describing above is a pretty good one... its a fairly established pattern too I think. Its very similar to JSP's PageContext or JSF's FacesContext which are essentially analogous to WebContext. Actually this could open up a couple of possibilities as well... it means that the table could render directly to the output stream or writer if appropriate for better performance. You might also want to consider providing methods specifying whether or not a response is even able to change headers or write binary content, etc. Exporters could then use this information to change their behavior or throw an exception. I'm thinking of a portlet's RenderReponse where headers can't be set and binary content should not be written, or of a servlet where part of the response has already been committed. In these cases, certain exports might still be relevant with fallback behavior (like a CSV or XML exporter could simply write HTML-escaped text to the response without setting headers), but others might need to throw an exception (XLS, PDF, etc).
Jul 30, 2008
(No comment was entered for this change.)
Labels:
-Type-Defect Type-Enhancement
|