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
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
