Could Stefan & Richard please remind
us as to when it is useful to have a render URL affect other portlets on a page
(just) for the duration of one page fetch, when a subsequent refresh (browser button)
is likely to revert to the previous consumer state (as nothing permanent is
being implied spanning consumer/portlets)?
I suspect any useful coordination state
change seems more related to a consumer effectively tracking and forwarding shared
values and so the Web request to the consumer should itself be a POST to the
consumer/Portal? Given PPs on render URLs that don’t last v.s. PPs in
action replies that do (SHOULD/MUST) aren’t developers going to choose
actions anyway, e.g. updating a charting page’s units from imperial to
metric?
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 25 July 2005 15:02
To:
wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
I think it might be time to pull this discussion back
out of the abstract space and relook at the use cases we have accepted as
compelling.
Stefan
& Richard have posted some use cases that clearly would benefit from PPs
being settable on URLs and need a PP scope of at least the user interaction ...
including all portlets accessed during the processing of the user interaction.
Could you post use cases requiring broader scopes? I presume that if we find
them compelling, my answer to Mike's previous inquiry about requiring Consumers
to support PPs may need to change.
Rich
|
Subbu Allamaraju
<subbu@bea.com>
07/25/05 09:06 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)
|
|
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
> >> >
> >>
> >>
> >
> >
>
>