You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2007/06/14 17:29:25 UTC
[jira] Created: (WICKET-651) New Wicket Portlet support: extending
IHeaderResponse and its usage to allow plugging in custom HeaderResponse
writing
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
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.
[jira] Resolved: (WICKET-651) New Wicket Portlet support: extending
IHeaderResponse and its usage to allow plugging in custom HeaderResponse
writing
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved WICKET-651.
------------------------------
Resolution: Fixed
Implemented
> 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
> 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.