Oh, I think the detached window changes are great for uPortal. I was
just commenting that it would be possible to do Detached without a
WindowState, if you didn't need to force it with a PortletURL. And I
think it's something we could look at in the design of things. Similar
to how Exclusive windowstate was done. It affected the very next call
(well really just that one url request) but after that, the window
state, did not appear to be exlusive to the porlet.
So, you could support a Detached window state, so that a portlet who
wants to write a portlet url to do that, can force it to happen. But
other portlets, can 'support' being detached, without needing any
uPortal specific code, as long as there is a portal control.
I would then encourage as many portlets hosted OUTSIDE of the uPortal
code base, to resist (or at least have it configurable) using the portal
specific window states, so they portlets can be used in other portals.
I would really like to avoid seeing JA-SIG portlets turn into the mess
that most of the JBoss and liferay portlets are, where they can't be run
outside of that portal.
So, to summarize my votes: yes - detached support for portlets in
uPortal. Yes - support for detached window state in portlet urls, for
portlets that want to do that. No (or make it optional) to most
portlets released into open source using portal specific portlet modes
or window states.
---- Cris J H
Eric Dalquist wrote:
The ability to do this via a PortletURL is the motivating factor for the
new WindowState. A detached portlet would be very similar from the
portlets view to being maximized. At least locally we'll have to allow
portlets to trigger this via a PortletURL.
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
--
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
