[
https://issues.apache.org/jira/browse/WICKET-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reopened WICKET-926:
------------------------------
I'm going to provide a little cleaner implementation, using better naming and
shortened coding (no functional or technical changes):
- Rename RequestCycle.nextUrlForNewWindow field -> urlForNewWindowEncoding
and RequestCycle.isNextUrlForNewWindow() -> isUrlForNewWindowEncoding()
- Move all IRequestCodingStrategy.encode(IRequestCycle, IRequestTarget) calls
into a new private final method CharSequence encodeUrlFor(IRequestTarget).
this method replaces the old resetNextUrlForNewWindow(CharSequence) which was
previously wrapping the return value of the encode calls in each urlFor method.
By merging all this into the new method (thereby also cleaning up quite a few
duplicated lines of code from the original RequestCycle too) the
urlForNewWindowEncoding handling
is now much cleaner encapsulated.
> 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.
