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/09/01 01:49:18 UTC

[jira] Updated: (WICKET-651) New Wicket Portlet support: extending IHeaderResponse and its usage to allow plugging in custom HeaderResponse writing

     [ https://issues.apache.org/jira/browse/WICKET-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma updated WICKET-651:
-----------------------------

    Affects Version/s: 1.3.0-beta3

> 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.