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 13:24:50 -0500
Agreed that such a mechanism could be
used productively, but it still looks like loading a gun for misuse as
I think the likelihood of render state being stored in such a mechanism
is relatively high. Any reason such an environment couldn't simply leverage
session state to pass the data (use a well-known key and clear it at the
end of the render phase)? It seems like this would be more efficient (the
data doesn't traverse the wire) and eliminate the need to introduce a new
concept at this stage of v2.
Also, how would such state impact cachability
of the portlet's fragment? If it is not included in the cache key, render
might not get called at all (how aggressive is the Consumer cache policy?).
If it is included (and cleared at end of getMarkup), would a page/portlet
refresh find the cached record (would we have to require the cache key
be generated after getMarkup returns)?
Rich
Michael Freedman <michael.freedman@oracle.com>
11/30/05 12:34 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Consumer Request Lifecycle
scope |
|
On creating a "bad" user experience, this would
be true if this scope is used to hold render state. By render state
I mean any state needed to rerender the portlet across lifecycles. This
scope should only be used for state that is only needed for the current
lifecyle. What is an example of this? Consider a portlet that
is built on a rendering engine that supports partial rendering [an ability
to render only what becomes dirty via an action]. Its conceivable
that such an engine will want to retain state to manage this between the
action and the render. However this state is only pertinent for this
lifecycle. A subsequent consumer page refresh doesn't need this state
-- in general it would just render the whole portlet.
As for your second comment: Yes, considering concurrency requires
a more sophisticated solution in the case that the producer manages the
state. In recognizing that it is currently a rare occurence that
a producer/portlet would use this state and that the consumer would also
uncommonly be in a situation that executes multiple concurrent requests
on the same portlet [within the same session] I would suggest that for
2.0 we merely disallow it. Allow the producer to register that they
useLifecycleScope and require the consumer to single thread concurrent
requests from the same user [session].
-Mike-
Rich Thompson wrote:
I have several concerns relative to heading in this direction:
1. 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.
2. 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:
a. 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).
b. Multiple
pages accessing the same portlet in parallel => coupled experience if
one of the pages was launched from the other.
c. ...
others?
Rich
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
--------------------------------------------------------------------- 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]