Communicating shared values through render
URLs does not seem to me an appropriate use. However, I was mainly criticizing the
duplication of mechanism (with reliance on Web URL and markup handling) and the
`better check & set if missing’ approach we are likely to require.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 22 July 2005 13:17
To: wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params)
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