[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)
I think this is mixing sematics. Anything that requires a pbia is ment
to be a resource state change. For resource changes you need a blocking
semantic. Navigational state and public params in my mind define the
view state of the portlet and changing this state does not require a
pbia nor a non-blocking action. The new parameters or state can just be
provided to the portlet.
This also relates to the W3C standard about GET and POST:
" * Use GET if:
o The interaction is more like a question (i.e., it is a safe
operation such as a query, read operation, or lookup).
* Use POST if:
o The interaction is more like an order, or
o The interaction changes the state of the resource in a way
that the user would perceive (e.g., a subscription to a service), or
o The user be held accountable for the results of the
interaction."
I don't see why it is necessary to pay the penalty of an action for
changing PPs.
Stefan
Subbu Allamaraju wrote:
> Rich Thompson wrote:
>
>>
>> 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?
>
>
> I agree, but the difference is the encoding rules.
>
> Subbu
>
>>
>> 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]