wsrp message
[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)
- From: Rich Thompson <richt2@us.ibm.com>
- To: "WSRP TC" <wsrp@lists.oasis-open.org>
- Date: Wed, 15 Jun 2005 11:01:17 -0400
I agree that I did not distinguish between
state the Consumer manages for its internal use and that which it manages
related to Portlets, but from an external point of view I doubt it
actually matters.
I also doubt complex values will be
used for public parameters, at least in the short term. However, I do think
the proposal needs to make allowance for them if for no other reason than
completeness.
Rich
"Yossi Tamari"
<yossi@giloventures.com>
06/15/05 09:49 AM
|
To
| "WSRP TC" <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] Additional use
cases for issue #44 (set new public params) |
|
Hi Rich,
I disagree with the statement
that modes and windowStates are aspects of consumer state. In my point
of view, they are aspects of the portlet state that are controlled by the
consumer (the consumer is not in edit mode – the portlet is – other portlets
may be in other modes at the same time).
As an aside, I expect adding
encoded (XML!) PP to the WSRP URL will create situations of URLs that are
too long for real world use, since the WSRP URLs are already pretty long.
Yossi.
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, June 15, 2005 4:25 PM
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]