[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 (setnew public params)
| "Andre Kramer"
<andre.kramer@eu.citrix.com>
07/26/05 10:05 AM |
|
| "Andre Kramer"
<andre.kramer@eu.citrix.com>
07/25/05 10:43 AM |
|
| Subbu Allamaraju <subbu@bea.com>
07/25/05 09:06 AM |
|
Stefan,
This is question of scoping.
As we have been debating, there are two options to let portlets update
some shared state (public params). The first option is to let portlets
encode such change in URLs, and the second is to let producers return
new public params within SOAP.
Apart from the encoding rules, these options influence scoping of this
shared state that consumers can implement. If you go with the first
option, consumers will have to limit this shared state to a user's
session or just a few portlets on a given page. IMO, this is restrictive.
However, if you go with the second option, consumer has more choice.
Consumers can implement wider scoping of this shared state.
Subbu
Stefan Hepper wrote:
> 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]