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(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]