Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44(set new public params)

[Subbu Allamaraju <subbu@bea.com>]

Rich Thompson wrote:
> 
> My comment was that requiring action processing is always possible, but 
> why would we require it in this case and not for 
> mode/windowState/navState changes?

I agree, but the difference is the encoding rules.

Subbu

> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 07/22/05 09:48 AM
> 
> 	
> To
> 	wsrp-interfaces@lists.oasis-open.org
> cc
> 	
> Subject
> 	Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 
> (set new public params)
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Thinking aloud, can't we map render URL use cases to use pbia? The
> reason for changing the value of a paramter could be the result of a
> user interaction, which can then compute new values and return with pbia
> response.
> 
> Subbu
> 
> 
> Rich Thompson wrote:
>  >
>  > It is possible to drive every style of update through action processing,
>  > but I think that short changes the advantages of using render URLs where
>  > they are appropriate.
>  >
>  > New navState can be specified on each URL (including render URLs), why
>  > should not the Portlet be able to specify the shared version (PPs)?
>  >
>  > Rich
>  >
>  >
>  > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>  >
>  > 07/22/05 08:02 AM
>  >
>  >                  
>  > To
>  >                  Rich Thompson/Watson/IBM@IBMUS, 
> <wsrp-interfaces@lists.oasis-open.org>
>  > cc
>  >                  
>  > Subject
>  >                  RE: [wsrp-interfaces] Fw: [wsrp] Additional use 
> cases for issue #44
>  > (set new public params)
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  > After reading your previous email, I was driving towards a similar
>  > recommendation for Portlets to “re-fresh” public parameters by return on
>  > each WSRP interaction so that a consumer is more likely to forward
>  > values that have been recently actively returned and I agree this means
>  > Portlets have to maintain/store public param values e.g. in navigational
>  > state. But, with such advice, I see no reason to have public parameters
>  > to visibly appear on URLs (rewrite expressions or templates) at all. Why
>  > introduce a new encoding and (in markup) transport mechanism when it
>  > seems a preferable Web Service (in SOAP response) encoding and transport
>  > is already available and recommended?
>  >  
>  > Regards,
>  > Andre
>  >  
>  >
>  > ------------------------------------------------------------------------
>  >
>  > *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
>  > Sent:* 22 July 2005 12:24*
>  > To:* wsrp-interfaces@lists.oasis-open.org*
>  > Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
>  > issue #44 (set new public params)
>  >  
>  >
>  > The Interfaces SC discussion raised the question about the scope of PPs
>  > set in this manner. Namely; does the Portlet need to keep specifying the
>  > PPs on all subsequent requests or can it depend on the Consumer to
>  > resupply those values in the future (i.e. some scope, like user-session,
>  > becomes mandated).
>  >
>  > I think we should be careful to leave scoping questions up to the
>  > Consumer, but if PPs are to function as a coordination model, then we
>  > also have to discourage Portlets from setting all PPs on every URL. A
>  > model where Portlets are encouraged to store current PP values
>  > (preferably in navState) for use as default values should the Consumer
>  > not supply a value on a subsequent invocation and only do PP setting
>  > when a value needs to change accomplishes this. It removes setting the
>  > value each time such that coordination happens in a more reasonable
>  > manner while also providing for reasonable user experience, even when
>  > the Consumer does not support and PP scope beyond the user interaction.
>  >
>  > Note: We could consider a model where Portlets MUST encode all PPs on
>  > all URLs such that this supplies the scope, rather than the Consumer
>  > determining the scope, but that this fails as the Portlet might not have
>  > access to all PPs (security and privacy reasons).
>  >
>  > Rich
>  >
>  > *Rich Thompson/Watson/IBM@IBMUS*
>  >
>  > 07/07/05 11:54 AM
>  >
>  >                  
>  > To
>  >                  wsrp-interfaces@lists.oasis-open.org
>  > cc
>  >                  
>  > Subject
>  >                  [wsrp-interfaces] Fw: [wsrp] Additional use cases 
> for issue #44 (set
>  > new public params)
>  >
>  >
>  >  
>  >
>  >
>  >                    
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > Reposting, as requested ...
>  > ----- Forwarded by Rich Thompson/Watson/IBM on 07/07/05 11:52 AM -----
>  >
>  >                    *Rich Thompson/Watson/IBM@IBMUS*
>  >
>  > 06/15/05 09:24 AM
>  >
>  >                        
>  >       To:        WSRP TC <wsrp@lists.oasis-open.org>
>  >       cc:        
>  >       Subject:        Re: [wsrp] Additional use cases for issue #44 (set
>  > new public params)
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > I had taken a to-do from the Interfaces SC to develop (in conjunction
>  > with Stefan, Richard and Mike) a proposal for this portion of Issue #44.
>  > Here is that proposal: *_
>  >
>  > Philosophy:_* Since Public Parameters (PP) are another aspect of
>  > Consumer managed state that is exposed to Portlets (the other two are
>  > modes and windowState), Portlets should be able to request changes to
>  > PPs in much the same way as they do modes and windowStates (on URLs and
>  > in responses from pbia and handleEvents). *_
>  >
>  > On URLs: (2 issues)_*
>  > 1. Need to encode 3 pieces of information (request to set a PP, the
>  > PPname and the PPvalue) into 2 places (name=value) when using a
>  > querystring and deal with the reduced set of characters allowed in the
>  > path portion ('=' is not allowed). Templates also introduce an issue
>  > with how to encode multiple PPs ... preferably with the Template only
>  > having a single placeholder.
>  > -Proposal:
>  > 1. All public parameters specified on a URL are concatenated in the form
>  > of "PPname1=PPvalue1&PPname2=PPvalue2".
>  > 2. The resulting string is URL encoded (changes '=' into %3D and '&'
>  > into %26) to make it valid in both the querystring and path portions of
>  > a URL.
>  > 3. This URL encoded string becomes the value for the
>  > wsrp-publicParameter URL parameter, regardless of whether template
>  > processing or Consumer URL rewriting is in use.
>  >
>  > 2. How to encode complex PPvalues? I suggest serializing the PPvalue to
>  > XML and URL encoding this XML. The Consumer would then receive the PP,
>  > recognize it is of a complex type (based on PPname) and decode the
>  > PPvalue to get the XML. *_
>  >
>  > On Operation responses:_*
>  > 1. Return PP requests via a field much as newMode and newWindowState
>  > request updates to those aspects of Consumer managed state. Suggest this
>  > field be of type QNamedStringArray, though it could be an array of
>  > NamedString if we do not want to introduce a usage of a type from the
>  > 'extra' namespace.
>  >
>  > Rich
>  >
>  > *Michael Freedman <michael.freedman@oracle.com>*
>  >
>  > 05/24/05 07:55 PM
>  >
>  >                  
>  >
>  >
>  > To
>  >                  WSRP TC <wsrp@lists.oasis-open.org>
>  > cc
>  >                  
>  > Subject
>  >                  Re: [wsrp] Additional use cases for issue #44 (set 
> new public params)
>  >
>  >
>  >
>  >
>  >                    
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > I too am interested in hearing people's current opinions.  Our early
>  > coordination discussions considered this carefully.  It was decided at
>  > that time to not support two coordination models that delivered
>  > equivalent function.  Though I pushed strongly for such a parameter
>  > style mechanism, the subcomittee preferred Events because it not only
>  > allowed state to be transferred but also actions.  The current public
>  > parameter model was introduced by me later and was crafted specifically
>  > to not step on the the toes of Events.  
>  >
>  > To extend this conversation I would like to pose:
>  > 1.        We consider whether publicParameters should be QNames so they
>  > can be shared/reused across producers.  Note: this is likely needed
>  > whether we stick with events or add the ability to encode a public
>  > parameter directly in the URL.
>  > 2.        We consider adding a new "defined event" called
>  > publicParameterValueChanged.  The payload of this event would be the
>  > QName of the parameter and an Object any holding the parmeter value
>  > [though it might be nice to support our Any/String optional pair style
>  > here].
>  > 3.        We consider defining the meaning of publicParameter whose
>  > capability contains the value "required" as meaning that normal usage of
>  > this portlet requires the consumer to provide this value.  The portlet
>  > would still have to deal with situations in which this wasn't provided
>  > but likely an end-user would consider this usage crufty/abnormal.  For
>  > example if a portlet required a CustID parameter and didn't receive one
>  > it could display a view that asks for a custID.  The key here by saying
>  > "required" [we can choose a different capability name] the consumer can
>  > distinguish between those public parameters that have a secondary impact
>  > on the portlet [optional] and those that have a primary or important
>  > impact [required].
>  > -Mike-
>  >
>  > Stefan Hepper wrote:
>  > Hi,
>  > I've some use cases that may be a good match for the ability to set new
>  > public parameters by the producer and to encode public parameters in
>  > URls by the producer.
>  >
>  > 1. displaying content based on a specific product id:
>  > - Portlet A allows to select a product from a list
>  > - User clicks on a specific product
>  > - Portlet B renders details of this product
>  > - Portlet C renders currently available number of items on stock for
>  > this product
>  > - user wants to bookmark this result in order to come back to product
>  > tomorrow
>  >
>  > implementation with events:
>  > Portlet A encodes the customer selection URLs as POST action links
>  > Portlet A receives a performBlockingInteraction call
>  > Portlet A returns event productID=10
>  > Portlet B receive a blocking handleEvents call for productID=10 and
>  > returns new navigational state
>  > Portlet C receive a blocking handleEvents call for productID=10 and
>  > returns new navigational state
>  >
>  > implementation with public params:
>  > Portlet A encodes the product selection URLs as GET render links with
>  > the productID as public param
>  > Portlet A receives a render call with the public param productID=10
>  > Portlet B receives a render call with the public param productID=10
>  > Portlet C receives a render call with the public param productID=10
>  >
>  > which would be much more efficient and also consistent with the W3C
>  > architecture as links that do only change view state should be encoded
>  > as GET links.
>  >
>  >
>  > 2. display content based on a specific customer id
>  >
>  > 3. display content based on the selected state of a map
>  > portlet A displays a map of USA
>  > portlet B displays information on the selected state (# people
>  > registered, capital, ...)
>  > portlet C displays all IBM labs in that state
>  >
>  > and many more.
>  >
>  >
>  > This would allow to have some gobal navigational state that can be set
>  > via URLs by portlets. Also portlets may want to set new public params as
>  > a result of an blocking interaction or a handle event call.
>  >
>  >
>  > What do you think?
>  >
>  >
>  > Stefan
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  You may a link to this group and all your TCs in
>  > OASIS
>  > at: _
>  > __https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>  >
>  > --------------------------------------------------------------------- To
>  > unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail. You may a link to this group and all your TCs in
>  > OASIS at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
> 
>