OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Consumer Request Lifecycle scope



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:
  1. 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).
  2. Multiple pages accessing the same portlet in parallel => coupled experience if one of the pages was launched from the other.
  3. ... 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]