Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.3.0-beta2, 1.3.0-beta3
-
None
-
None
-
None
Description
IHeaderResponse is used in HtmlHeaderContainer and AjaxRequesTarget for collecting header contributions to be streamed out first before the rest of the response.
In a portal environment the real response isn't under control of a portlet and writing to the html head section of a page isn't possible (yet, Portlet API 2.0 might add some support for it).
As a simple solution, a portlet can embed (loading external) javascript and/or css directly into the markup, but it shouldn't wrap it in a <head></head> section as HtmlHeaderContainer is doing right now.
Furthermore, some portals might already provide some custom extensions which could allow porlets to contribute to the final page head section (Jetspeed-2 for instance does).
To allow intercepting HeaderResponse writing, I'm extending IHeaderResponse with a close() and isClosed() methods so a plugged in HeaderResponse implementation will be able to know when the response should be flushed.
Furthermore, I'm moving the getResponse() method up to HeaderResponse (final) and delegate it to a new protected abstract getRealResponse() method.
Finally, the HtmlHeaderContainer will check the new RenderContext.getHeaderResponse() to see if a custom IHeaderResponse implementation should be used (the default implementation will return null).
These changes all are non-intrusive and without any functional side-effect and could be applied to the Wicket core trunk without dependencies on the real portlet support.