|Michael Freedman||Nov 29, 2005 3:30 pm|
|Rich Thompson||Nov 30, 2005 7:29 am|
|Michael Freedman||Nov 30, 2005 9:33 am|
|Rich Thompson||Nov 30, 2005 10:26 am|
|Michael Freedman||Nov 30, 2005 10:28 am|
|Michael Freedman||Nov 30, 2005 10:47 am|
|Subbu Allamaraju||Nov 30, 2005 5:16 pm|
|Michael Freedman||Dec 6, 2005 11:27 am|
|Subject:||Re: [wsrp] Consumer Request Lifecycle scope|
|From:||Michael Freedman (mich...@oracle.com)|
|Date:||Nov 30, 2005 9:33:49 am|
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?
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