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

[Subbu Allamaraju <subbu@bea.com>]

Render URLs can already be handled with WSRP1.0. For instance, with 
JSR168, portlets can send mode/windowState on render URLs without 
special provisions in WSRP.

Subbu

Rich Thompson wrote:

>
> I think the use case for any of them being on the URL is render URLs. 
> Specifying them on the URL allows such inputs while short-circuiting 
> the action processing step(s) of the protocol, resulting in improved 
> cacheability and performance.
>
> Rich
>
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/15/05 11:15 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS, "WSRP TC" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
> 	
>
>
>
>
>
> I understood it to be an optimization. i.e. the consumer can indicate 
> that it is willing to accept a new window state or mode switch by 
> calling performBlockingInteraction with the values supplied on the 
> URL. I’m not convinced that’s the case for public params in general.
>
> -- Andre
>
> ------------------------------------------------------------------------
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 15 June 2005 16:04*
> To:* WSRP TC*
> Subject:* RE: [wsrp] Additional use cases for issue #44 (set new 
> public params)
>
>
> The use cases Stefan posted to start this thread need public 
> parameters to be set on the URL.
>
> Other other question I would ask is why doesn't the same argument 
> apply to mode and windowState? (i.e. I am arguing for consistency as 
> well as efficiency)
>
> Rich
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 06/15/05 09:35 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS, "WSRP TC" <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [wsrp] Additional use cases for issue #44 (set new public params)
>
>
>
> 	
>
>
>
>
>
>
> I can subscribe to the philosophy of portlets requesting updates to 
> public parameters but why do they need to be able to request update 
> via markup URLs (i.e. on link activation). Surely, a much simpler 
> model would be just to let performBlockingInteraction and friends 
> return/output as well as take as input public parameters? That would 
> tie into the event model better as portlets would have the chance to 
> coordinate such updates if an update was a subscribable event.
>
> Regards,
> Andre
>
>
>
> ------------------------------------------------------------------------
>
> *
> From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 15 June 2005 14:25*
> To:* WSRP TC*
> 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 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
>