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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

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


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



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?

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
>




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