My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 129: Exports Depend on HttpServletResponse
1 person starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----


 
Reported by bgo...@e1b.org, Jul 29, 2008
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
I agree with that. I remember when I created the exports thinking that I might run
into this situations down the road. At the time I felt like I was over-designing that
part and opted not to do that.

Just thinking off the top of my head I wonder if we would keep the WebContext but
then inject it with a WebRequest and WebResponse. The current WebContext methods
could be placed on the WebRequest. The methods on the current WebContext would also
still be on the WebContext, but deprecated and used as a pass through to the WebRequest.

Doing any kind of change like this would require us to bump the API up a whole
version as there could be a little breakage. It would also give me a logical time to
make the TableFacadeImpl method protected as I would prefer developers to use the
TableFacadeFactory. In addition I think it would make more sense to set the response
(aka WebResponse) on the TableFacadeFactory as well instead so you do not have to
declare it when you specify the export types.

Just thinking out loud right now. I should diagram some ideas out.

Jul 29, 2008
#2 extremec...@gmail.com
(No comment was entered for this change.)
Status: Accepted
Jul 30, 2008
#3 bgo...@e1b.org
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
#4 extremec...@gmail.com
(No comment was entered for this change.)
Labels: -Type-Defect Type-Enhancement

Powered by Google Project Hosting