OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp] comment regarding interactionState


Let me see, by way of an example, if I understand you correctly.  And then I'll have a question about how this works with form actions...
 
PortletA embeds an action URL into its markup:  wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-interactionState=foo/wsrp-rewrite   (By the way, the action example in the spec 10.2.1.8 has "interactionState", not "wsrp-interactionState"...signficant?) 
 
Consumer streams portlet markup, including the following rewritten action URL:   http://www.myportal.com/wsrpProxy/portalA?interactionState=foo
 
End-user clicks the URL, and Consumer invokes:  performBlockingInteraction(...PortletContext.portletHandle="A"...InteractionParams.interactionState="foo"...). 
 
InteractionState does not persist beyond the lifetime of the request. 
 
Now, if the portlet were creating a form, and the action was associated with the submit (POST) for the form, then of course it could specify no query params in the URL...so that, if it wanted interactionState associated with the form action, it would have to embed it as a hidden field. 
 
Does this reflect what you're saying?
 
Alan
 
 
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, June 02, 2003 12:00 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] comment regarding interactionState


I see the confusion. The wsrp-interactionState portlet URL parameter is effectively a pass-through to the Consumer. If the Consumer is doing url-rewriting and an "url" specifies this parameter, then the Consumer outputs the value (or a reference to it) on the actual URL streamed to the browser. When an action URL is activated, the Consumer "reads" the value out of the URL and writes it to the interactionParams structure. The only case where the Consumer has to do something with the parameter (and its value) is when all portlet url parameters are referenced through an indirection. In this case, the Consumer does need to store the value so that it can be found when the URL is activated.

Rich Thompson



"Kropp, Alan" <Alan.Kropp@vignette.com>

06/02/2003 02:05 PM

       
        To:        Rich Thompson/Watson/IBM@IBMUS, "'wsrp@lists.oasis-open.org '" <wsrp@lists.oasis-open.org>
        cc:        
        Subject:        RE: [wsrp] comment regarding interactionState



I guess my confusion stems from the fact that the portlet can construct an
url template that includes wsrp-interactionState, but what is the Consumer
(if it's the URL rewriter) expected to replace this parameter with?  Unlike
with navState, this field's expected value is never directly conveyed from
the portlet to the Consumer (i.e., via a response from
performBlockingInteraction).

What is the Consumer expected to replace this with when rewriting the URL?

Alan


-----Original Message-----
From: Rich Thompson
To: wsrp@lists.oasis-open.org
Sent: 6/2/2003 11:52 AM
Subject: RE: [wsrp] comment regarding interactionState


The purpose of interactionState is to pass a set of opaque parameters to
performBlockingInteraction. Any state impact lasting longer than the
request needs to be either in navState or portletState (depending on how
long it is to last). The current semantics are that interactionState is
only passed when the user activates an URL that specifies a value for
wsrp-interactionState. For something targeted as opaque action
parameters, this seems like the right semantics.

Why would we want a second opaque parameter with the same semantics as
navState? The only reason navState has semantics beyond interactionState
is to handle page refresh (including the case of the user interacting
with a different portlet on the page).

Rich Thompson



                "Kropp, Alan" <Alan.Kropp@vignette.com>


06/02/2003 12:02 PM        
       To:        "'Andre Kramer '" <andre.kramer@eu.citrix.com>,
"''wsrp@lists.oasis-open.org' '" <wsrp@lists.oasis-open.org>
       cc:        
       Subject:        RE: [wsrp] comment regarding interactionState




I believe that's the intent.  



-----Original Message-----
From: Andre Kramer
To: 'wsrp@lists.oasis-open.org'
Sent: 5/30/2003 2:54 PM
Subject: RE: [wsrp] comment regarding interactionState

Would this then not just be equivalent to navigationalState? We need a
way to pass up data *without* determining what is sent in future actions
- which is what interactionState provides now?

regards,
Andre

-----Original Message-----
From: Kropp, Alan [ mailto:Alan.Kropp@vignette.com
<mailto:Alan.Kropp@vignette.com> ]
Sent: 30 May 2003 19:28
To: 'wsrp@lists.oasis-open.org'
Subject: [wsrp] comment regarding interactionState


We allow for interactionState to be sent to the Producer in
InteractionParams, yet there is no corresponding response that contains
the
portlet's most recent value for this field.

I think this needs to mirror how we handle navigationalState:  the
UpdateResponse should carry two state fields:  navigationalState, and
interactionState.

In terms of conformance:  the portlet MAY choose to set a value for
interactionState, in which case the Consumer MUST return it on
subsequent
action invocations only.  

Alan




You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou
p.php
<http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgro
up.php>


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou
p.php




You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]