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 18:27:25 UTC
[jira] Created: (WICKET-654) New Wicket Portlet support:
translating Wicket relative paths back to fully qualified paths for usage
in a portlet context
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
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.
[jira] Commented: (WICKET-654) New Wicket Portlet support:
translating Wicket relative paths back to fully qualified paths for usage
in a portlet context
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504801 ]
Ate Douma commented on WICKET-654:
----------------------------------
Initial implementation committed, probably needing further improvement, so I'll leave this issue open for now.
> 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
> 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.