[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Additional use cases for issue #44 (set new public params)
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]