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