[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)
> > One potential way to call out that the PP model is not a "session" > would be to call out the semantics of what needs to be supplied to a > Portlet as PPs when the Consumer does not support PPs. I would suggest > that any values pushed to the Consumer (either via the URL or a > response from pbia or handleEvents) have to be supplied to subsequent > invocations on the Portlet during the processing of that particular > user interaction. This encourages Portlets to move state changes that > might have been encoded in the opaque navState out to PPs. To make this round-tripping work, the portlet must keep encoding this state within each URL it generates, which makes it similar to navState. The only difference I see is that public params would become a global shared state. I doubt if it is realistic to attempt to encode such state in URLs. Subbu > > Rich > > > *"Yossi Tamari" <yossi@giloventures.com>* > > 06/15/05 12:45 PM > > > To > "WSRP TC" <wsrp@lists.oasis-open.org> > cc > > Subject > RE: [wsrp] Additional use cases for issue #44 (set new public params) > > > > > > > > > > What it means is that “public parameters” becomes much like a > “session” object (a container managed collection of properties that > are available at any request and can be set by the portlet). > Two portlets on the page can then share a session-scoped property, > regardless of whether this property in known to the consumer. I think > what both Subbu and me are saying is that the changes proposed here go > 90% of the way to this, and users of the protocol will expect the > remaining 10%. > > Yossi. > > ------------------------------------------------------------------------ > > *From:* Rich Thompson [mailto:richt2@us.ibm.com] * > Sent:* Wednesday, June 15, 2005 7:26 PM* > To:* WSRP TC* > Subject:* RE: [wsrp] Additional use cases for issue #44 (set new > public params) > > > What would it mean for a Portlet to change a public parameter that the > Consumer is not aware of? Public parameters are managed at the > Consumer. Portlets can certainly do computations and end up using > values other than what the Consumer supplied, but they haven't > actually changed the parameter unless they tell the Consumer of the > change. Instead they have only manipulated and then used some internal > value. > > In other words, just because the Consumer supplies "06611" (my > zipcode) as the value for a public parameter called "zipcode" to a > weather portlet doesn't mean the portlet isn't free to display weather > data about some other zipcode. I, as the user, might choose to stop > using such a portlet, but that doesn't mean the protocol is > restricting the portlet to using the value as supplied. > > Rich > > *"Yossi Tamari" <yossi@giloventures.com>* > > 06/15/05 12:10 PM > > > To > "WSRP TC" <wsrp@lists.oasis-open.org> > cc > > Subject > RE: [wsrp] Additional use cases for issue #44 (set new public params) > > > > > > > > > > > … And there you said it: Public parameters have become a > transparent-to-the-Consumer state of the portlet, rather than the > transparent-to-the-Portlet state of the consumer. > > I just feel we need to keep these things out in the open rather than > try to avoid actually saying them. Because I have no doubt that the > next question that will be asked is what happens if the portlet > “changes” a public parameter that the consumer is not aware of. > > Yossi. > > > > ------------------------------------------------------------------------ > > * > From:* Rich Thompson [mailto:richt2@us.ibm.com] * > Sent:* Wednesday, June 15, 2005 7:03 PM* > To:* WSRP TC* > Subject:* Re: [wsrp] Additional use cases for issue #44 (set new > public params) > > > I think the use case for public parameters on render URLs also relates > to them effectively being an extension to the opaque navState of WSRP > v1. One can change the opaque portion of the navState on render URLs, > why not the transparent-to-the-Consumer portion? > > Rich > > *Stefan Hepper <sthepper@hursley.ibm.com>* > > 06/15/05 11:51 AM > > > > > To > Rich Thompson/Watson/IBM@IBMUS > cc > WSRP TC <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] Additional use cases for issue #44 (set new public params) > > > > > > > > > > > > It also makes a hugh difference from the HTTP protocol point of view as > pbia need to be implemented as HTTP POST whereas you would only need > HTTP GETs for changing public parameters. Otherwise how could you comply > with the W3C architecture? > Also search engines like google very much count on this distinction in > order to follow links. > > Stefan > > 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 > > > > > > --------------------------------------------------------------------- > 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]