[
https://issues.apache.org/jira/browse/WICKET-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved WICKET-651.
------------------------------
Resolution: Fixed
Through the default provided EmbeddedPortletHeaderResponse this already works
quite nicely.
I haven't even yet started integrating this in the proprietary (for now, until
Portlet API 2.0) header extension of Jetspeed-2, but it doesn't even seem to
really needed.
Something to look into further once Portlet API 2.0 containers become available.
> New Wicket Portlet support: extending IHeaderResponse and its usage to allow
> plugging in custom HeaderResponse writing
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-651
> URL: https://issues.apache.org/jira/browse/WICKET-651
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.3.0-beta2, 1.3.0-beta3
> Reporter: Ate Douma
> Assignee: Ate Douma
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
