[
https://issues.apache.org/jira/browse/WICKET-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved WICKET-926.
------------------------------
Resolution: Fixed
cleaner implementation committed
> New Wicket Portlet support: Support for detached/popup pages
> ------------------------------------------------------------
>
> Key: WICKET-926
> URL: https://issues.apache.org/jira/browse/WICKET-926
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket, wicket-portlet
> Affects Versions: 1.3.0-beta3
> Reporter: Ate Douma
> Assignee: Ate Douma
>
> Supporting statefull detached/popup pages from a Portlet is tricky business.
> With JSR-168, Portlet API 1.0, this is completely impossible without using
> portal specific extensions.
> In JSR-168, a portlet is only allowed to write out content the render phase.
> That content is, potentially together with content produced by other
> portlets, aggregated by the portal in one single page before it is send out
> to the client.
> Furthermore, as each render or action request may change portlet navigational
> state maintained by the portal, even if you would create a page with a single
> portlet, interacting with that portlet through the popup window can cause
> navigational state changes which is not reflected on the page containing the
> original portlet initiating the popup page (window). So, after coming back to
> that portlet window, interacting with it might result in unexpected/invalid
> behavior.
> But, with JSR-286, Portlet API 2.0, this now changes :)
> The new Portlet ResourceURL and serveResource phase will allow "directly"
> calling a portlet, albeit still only through the portal, and has full control
> over the response/content it produces.
> Furthermore, navigational state changes are not allowed/possible during
> serverResource thus there is less danger of inconsistent state between the
> two browser windows. Note: you are allowed to changes server state like the
> session or the portlet preferences.
> Using the preliminary, pre-JSR-286 support for ResourceURLs from Apache
> Portals Bridges (PB-65) which I already integrated in wicket, rendering
> detached/popup pages is possible to implement.
> Although, because JSR-286 nor container implementations are available yet, at
> runtime we still need a portal specific implementation for handling
> ResourceURLs.
> But, for Wicket there is another problem: how to detect when a page url is
> going to be used for opening a popup page?
> There are many different ways to create an url, but in a servlet environment,
> it doesn't matter if it will be used as popup or not: they are just the same.
> All (most all) Wicket url generation is manged through
> RequestCycle.urlFor(..) calls which delegates this in the end to the
> RequestEncodingStrategy.encode(..).
> For Wicket portlet-support, the only sensible location to "intercept" page
> url generation is within the RequestEncodingStrategy.encode(..) method, see
> WICKET-655, but there it is currently impossible to detect what the usage of
> the url will be (popup or non-popup).
> To solve this there are 3 different solutions AFAICS:
> a) Add a boolean popup parameter to to RequestEncodingStrategry.encode(...)
> This solution will have a very big cascading effect as this means adding this
> parameter to all RequestCycle urlFor methods, and from there to Component and
> all its children which override or call that method. Of course, the current
> method signatures should also be preserved with a default value false, but
> still ...
> b) Find some other way to pass the popup target information through the
> calling chain, like setting some transient property on the (page) Component.
> This won't be possible with one a single solution though as there are so many
> different ways urlFor can be called.
> c) Add a "hacky" temporary flag in RequestCycle only valid for the duration
> of one urlFor method call, indicating if the next call is intended for a
> popup or not.
> Yes, I know this isn't going to win a coding beauty contest either, but
> neither will the above alternatives.
> As solution c) is at least the least intrusive, I've chosen to implemented
> that for now.
> I'm definitely all ears if someone can come up with: "hey dude, that's what I
> call mighty stupid! Why not use this much easier and cleaner solution..." :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
