Also, if any bits of these two issues seem a bit too narrow for uPortal in general please say-so we can always do these local-only first and go from there. I'd just rather do it in uPortal core and forgo the local-only step if everyone is comfortable with that.
-Eric Cris J Holdorph wrote:
I think a new Portlet Window for the same portlet entity is the right way to handle detached. However, it strikes me, that if you go that route, a new WindowState may not be needed at all. Unless there's some reason for a portlet to care that they are in a separate window, I think a new window state just encourages coding portlets that are not as portable. The only 'upside' I could see, is the ability to create a PortletURL that would cause the detached behavior, rather then relying on Portal controls.---- Cris J H Eric Dalquist wrote:For the DETACHED WindowState:- The use-case here is a portlet that pops open search results in new windows. These results would be able to be further refined by the user via controls in the pop-up window while the user can still interact with the original portlet on the tab. - The portlet object model does support the idea of multiple PortletWindows into one subscribed PortletEntity, this scopes the request parameters, WindowState and PortletMode from each instance the user interacts with while the session and preferences are still shared.I hope that helps clarify a bit. I'll update the jira issues later today.-Eric
smime.p7s
Description: S/MIME Cryptographic Signature
