RE: [wsrp] redirectURL mutually exclusive with interactionResponse

Well, 
it turns out that our wsdl does not enforce this mutual exclusiveness (lack of 
web stack support for xsd:choice). Here is what we would return from 
performBlockingInteraction, if we addressed this issue:

 

BlockingInteractionResponse

    [O] SessionContext sessionContext

    [O] PortletContext portletContext

    [O] string redirectURL

    [O] UpdateResponse updateResponse // mutual exclusive 
with redirectURL

 

UpdateResponse 

    [O] MarkupContext markupContext

    [O] navigationalState navigationalState

    [O] string newWindowState

    [O] string newMode

 

I 
would also put in a note to say that the consumer must keep a portlet's 
navigational State as is on a redirect. [And add a "boolean requiresRewrite" to 
BlockingInteractionResponse to tell the consumer to re-write the content 
returned by redirectURL.]

 

The 
above actually seems clearer to me, in that is leaves out the extra 
InteractionResponse level that we currently have (and allows a more direct 
comparison with performNonBlockingInteraction).

 

regards,

Andre

  
-----Original Message-----
From: Rich Thompson 
  [mailto:]
Sent: 25 March 2003 17:43
To: 
  
Subject: RE: [wsrp] redirectURL mutually 
  exclusive with interactionResponse

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 
        <> 
        
03/25/2003 11:00 AM 

              
        To:     
           Rich Thompson/Watson/IBM@IBMUS 
        cc:     
           Andre Kramer <> 
        
        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