[
https://issues.apache.org/jira/browse/WICKET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483069
]
Jonathan Locke commented on WICKET-391:
---------------------------------------
Well, setter was probably a bad idea, but we could have just one WebResponse
class that decides whether to buffer automatically based on settings. That way
we don't have this code:
protected WebResponse newWebResponse(final HttpServletResponse
servletResponse)
{
return (getRequestCycleSettings().getBufferResponse() ? new
BufferedWebResponse(
servletResponse) : new
WebResponse(servletResponse));
}
With this code, to create my own response subclass, I would have to duplicate
this logic and cut and paste to extend both BufferedWebResponse and
WebResponse. What I'd like to be able to do is just extend WebResponse and
know it will work no matter what the settings are.
> Fold BufferedWebResponse into WebResponse to allow extension of both
> --------------------------------------------------------------------
>
> Key: WICKET-391
> URL: https://issues.apache.org/jira/browse/WICKET-391
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3
> Reporter: Jonathan Locke
> Fix For: 1.3
>
>
> currently our webresponse subclasses are not extensible because they are
> dynamically picked when constructed by the factory method in session based on
> application settings. we should consider folding bufferedwebresponse into
> webresponse. we would lazy init the appendingstringbuffer to avoid
> constructing that unless buffering is required and provide a boolean setter
> to turn on/off buffering (that's probably where the buffer init should
> happen).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
