Would this mean that a _wsrp_rewrite and rewrite
template contains something like wsrp-parameters=(encoded
name=value&name=value...) where the parameters specified would set some
consumer held parameter state and then forwarded on to the appropriate
portlets.
If the render URL is used and they are shared
parameters wouldn't the consumer have to be careful in calling portlets, since
it may effect other portlets interested in the parameter value. i.e. order and
which portlets i.e. to update cache
----- Original Message -----
From:
Rich Thompson
To:
Sent: Friday, July 22, 2005 8:16 AM
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" <>
07/22/05 08:02 AM
To
Rich
Thompson/Watson/IBM@IBMUS,
<>
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:]
Sent: 22 July 2005 12:24
To:
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
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
<>
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
<>
05/24/05 07:55 PM
To
WSRP TC
<>
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
