wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Consumer Request Lifecycle scope
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 30 Nov 2005 10:28:22 -0500
I have several concerns relative to
heading in this direction:
- It seems like this "feature"
would make for a bad user experience. Consider the common case of an action
invocation followed by an indeterminate number of page (or portlet) refreshes.
Is this scope actually of action->action duration, with the relevant
impacts on the Consumer, or does the rerendering of the portlet lose this
state and therefore the markup change in an unexpected manner? I suspect
the Producer-desired behavior is more likely to result in a reasonable
user experience if the current types of state (i.e. session and navState)
are leveraged rather than this new one added.
- You call out several possible
solutions with their pros and cons. I think we would need to carefully
consider some of the use cases where either independent or a coupled user
experience is expected. A couple of these are:
- Multiple browsers instances,
includes potentially different browser impls (I have IE, Mozilla, Firefox
and Opera installed) all accessing the same page (e.g. same home page,
most sharing a single user login).
- Multiple pages accessing the
same portlet in parallel => coupled experience if one of the pages was
launched from the other.
- ... others?
Rich
Michael Freedman <michael.freedman@oracle.com>
11/29/05 06:31 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsrp] Consumer Request Lifecycle scope |
|
When we discussed transient properties I talked about
a scope representing the extent of a single client request in the consumer.
I.e. the execution of one complete lifecycle as we define it in wsrp.
At the time I indicated this scope was largely needed by producers
to manage portlet specific (non-shared) data. Because it wasn't a
shared thing we dropped it. Upon further reflection and after gaining
more experience with adapting environments such as JSF to wsrp I think
we would be well served to define a mechanism in wsrp 2.0 to facilitate
managing producer state a this scope albeit a mechanism not based on transient
properties.
The problem:
Some portlet development models, though distinguishing between an action
phase and a rendering phase, assume that these phases (typically)
complete within a single request lifecycle. In so doing they rely
on an ability to maintain state between these phases which either implicitly
or explicitly is removed when the scope ends. Unfortunately wsrp
doesn't provide any means for a producer to detect/manage such a scope.
Two possible solutions:
1. Have
the consumer provide a lifecyle id in the Runtime context. This id
is the same for each call in a single lifecycle but unique for each new
lifecyle.
Pluses: Relatively simple and straightforward addition. Relatively
easy for consumers to implement -- for example a consumer could use the
current time as the lifecycle id.
Minuses: Producers detect the termination of scope by recognizing a new
scope has begun. Producers may want/need to account for detecting
termination by inactivity.
2. Introduce
a new consumer managed opaque state concept akin to portlet sessionContext
(perhaps called requestContext). Like the sessionContext the requestContext
is passed to each lifecycle operation [action, event, render] and returned
from each. Unlike sessionContext the requestContext would not be
a reference; it would represent the state directly via a binary (opaque)
field. At the beginning of a lifecycle [first call in a lifecycle]
the consumer would pass a null value [omit] for this field. For
the duration of the lifecyle the consumer would pass whatever the producer
had previously returned from the previous call in the lifecycle. At
the completion of the lifecycle, the consumer would discard the state.
Pluses: Consumer discards state at end of scope. Producer has
no worries for detecting/managing.
Minuses: (1) Producer needs to be able to prepare its state so it
can be passed as an opaque binary field and receive such. This may
not be something the higher level portlet environment models. (2)
Data sets might be large making it inconvenient/inappropriate to send across
the wire. (3) If the producer decides to send a reference instead
of the data itself it still has the minuses discussed above. Note it recongizes
a requestContext whose data is null as an indicator that a new lifecycle
has started so the previous is out of scope.
-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]