On further reflection, single threading a lifecycle would prevent the
concurrent lifecycle requests from interacting via events -- again not
something that is to likely yet but certainly more troublesome.
Another possible solution is to have the Lifecycle context structure
contain a field that indicates whether the current call is the last in
the lifecycle and hence terminates the scope. This would allow a
portlet to have multiple active lifecycle scopes within a single user
session and terminate either when this flag is set/sent or via timeout
in those situations the consumer never calls back to the producer to
"logically" complete the scope.
-Mike-
Michael Freedman wrote:
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:
- 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
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
|