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:
- 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.
- 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].
- 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
|