wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] TransientProperties
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 22 Jun 2005 16:19:39 -0400
Wouldn't it be better to view these
as two different scoping concepts, one is LifetimeScope and the other is
SharingScope? I raise this because I suspect not only would additional
lifetime scopes be added in the future, but also additional scopes for
the sharing such data. This also allows unifying the concepts, from the
portlet's perspective, each transient property has a lifetime and a breadth
within which it is shared (minimum = private, maximum = public). There
would be no need to distinguish the sharing breadth at runtime, though
we should think carefully through the implications of multiple portlets
indicating different sharing breadths for a particular property.
I think the questions on managing these
scopes in the midst of conflicting metadata will still result in the model
where the Consumer maintains a store of transient properties and a mapping
layer for each portlet. This allows the property QName, lifetime and sharing
scope to all be dealt with at the portlet-specific layer while the bulk
of the coordination behavior happens at the shared layer.
Rich
Michael Freedman <michael.freedman@oracle.com>
06/21/05 05:10 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrp] TransientProperties |
|
Here is the writeup I volunteered to produce last week
which extends the current notion of PublicParameters to add transient property
like capabilities. This should get people's juices flowing:
Summary:
Address the various incoming requirements by adding two new concepts:
1. TransientProperties:
properties whose values are managed by the consumer for a transient
length of time [as defined by a consumer scope].
2. Shared
PublicParameters vs. Local PublicParameters: distinguish between
two types of public parameters. Shared public parameters are shared
in that they are defined a single consumer managed namespace. Local
public parameters aren't shared in that they are defined in a per [wsrp]
portlet namespace.
The first concept allows a producer to indicate the lifetime
this property should be maintained. Request means the property's
value is only maintained for the duration of the client request. Current
or new values must be established in each subsequent request. Session
means the property's value is maintained for the duration of the consumer's
client/user session. While the session remains intact, the property's
value is maintained until explictly set.
The second concept allows a producer to indicate whether the property it
is placed in a global shared consumer space or a local per portlet space.
The former allows two or more cooperating consumer component's to
share a value while the later ensures the portlet has a discretely managed
value [though this value may be impacted by others via a consumer supplied
wiring mechanism].
Note: An open, unresolved issue is whether the transient property
scope is considered part of the namespace or not. I.e. what do we
do if two portlets publish a shared public parameter foo.bar but each publishes
at a different transient scope [request and session]? Do we use these
scopes as "hints" and defer to the greater scope [session]? Do
we publish at each scope and view them as separate values?
Setting values:
A shared or local public parameter value can be set in a variety of ways:
1. By
the client -- we would define the URL parameter name mapping to both shared
and local public parameters so clients can express values for them directly
in the request URL. Note: we would have to define what happens if duplicate
parameters appear in the request for a scalar type.
2. In
a portlet's Action or Render URL - based on the name mapping defined above
we would allow portlet's to render action and render URLs which directly
express new values for either shared or local public parameters.
3. As
a result of an action or event.
Details of each of these to be provided later if the general
appraoch is abgreed upon.
Anyway: the structural details:
For review:
PropertyDescription
[R] QName name
[R] QName type
[O] LocalizedString label
[O] LocalizedString hint
[O] string capabilities[]
[O] Extension extensions[]
TransientPropertyDescription extends PropertyDescription
[R] string scope [wsrp:request, wsrp:session,
.... open ended list so new scopes can be added]
RuntimeContext
[R] string userAuthentication
[O] Key portletInstanceKey
[O] string namespacePrefix
[O] Templates templates
[O] ID sessionID
[O] Property sharedPublicParameters[]
[O] Property localPublicParameters[]
[O] Extension extensions[]
-Mike-
---------------------------------------------------------------------
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]