wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] redirectURL mutually exclusive with interactionResponse
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 25 Mar 2003 12:42:55 -0500
The discussion to-date has been that
the Portlet can not ask the Portal to do such things when it is doing a
redirect. The net effect for the cases you raise would be the Producer
throwing away the cloned Portlet (it never really got used to generate
markup anyway) and any new session. We may want to revisit this for
v2, but at this point I would keep the exclusion for v1 (it is always easier
to relax than to tighten such constraints).
Rich Thompson
| Andre Kramer <andre.kramer@eu.citrix.com>
03/25/2003 11:00 AM
|
To:
Rich Thompson/Watson/IBM@IBMUS
cc:
Andre Kramer <andre.kramer@eu.citrix.com>
Subject:
RE: [wsrp-wsia] [change request #246]
userProfileItemDescriptions rename |
Rich,
It may be that blockingInteractionResponse.redirectURL
and blockingInteractionResponse.updateResponse.interactionResponse are
not mutually exclusive after all!
A producer may like to do a clone
before write (some portlet property needs to be set), establish a session
(pushing back a sessionID to the consumer), and even update nav state and
then decide to do a consumer re-direct.
Presumably, the user will later
come back to the consumer portal page and should then be able to access
the cloned portlet (and the session if it has not timed out).
I've not thought this one through
fully but we currently don't allow a new portletContext and a re-direct
URL to be returned together?
regards,
Andre
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]