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:19 UTC

[jira] Updated: (WICKET-654) New Wicket Portlet support: translating Wicket relative paths back to fully qualified paths for usage in a portlet context

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

Ate Douma updated WICKET-654:
-----------------------------

    Affects Version/s: 1.3.0-beta3

Switching to a new 1.3.0-beta3-portlet-support branch

> New Wicket Portlet support: translating Wicket relative paths back to fully qualified paths for usage in a portlet context
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-654
>                 URL: https://issues.apache.org/jira/browse/WICKET-654
>             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
>
> Wicket has the very nice feature of only generating current page relative url paths which is great when working behind mod_proxy.
> But for a portlet, their is no such thing as "current request path", and thus relative paths makes no sense here.
> Actually, the WicketPortlet solution will rewrite all wicket urls as PortletURL with the targetted wicket url as embedded parameter.
> So, when running in a portlet context (RenderContext.isEmbedded()), the Request.getRelativePathPrefixToContextRoot() and .getRelativePathPrefixToWicketHandler()  need to adapted to return a prefix which will make the generated wicket url fully qualified again against the base/domain url.
> This might seem like a problem for environments behind mod_proxy (and it might), but when you run a portal this is a common/known issue.
> The changes I'll commit against this issue are only effective when RenderContext.isEmbedded() == true, so this will have no effect in the normal case. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.