Well, I think we are just arguing over details ... both schemes seem
based on the same premise with your being generic and hence more chatty
while mine is targeted and hence more efficient.
I.e. wsrp:removeNavigationalContextDelta vs.
wsrp:newUserInteractionSet. Aren't these really the same in that they
indicate a context change has occurred and that any producer managed
transient state related to the navigationalContext should be
released/not used? Maybe a good name for the event is:
wsrp:releaseTransientNavigationalContext. The main difference is the
frequency this is sent. My proposal only sends this event if the
portlet (in getResource) has indicated it has
transientNavigationalContext. Your proposal assumes that a portlet
subscribing to such an event is always behaving this way and needs
notification.
as for wsrp:updateNavigationalContext vs. your
wsrp:updateNavigationalContext aren't we again defining the same
thing? It seems both a meant to allow the consumer to give the
producer an opportunity to reexpress/update its navContext with the
distinction once again that in my case the consumer is informed under
what circumstances this might be interesting.
Is one of the reasons you went down the path you did because you really
want this to apply to the getMarkup case as well? If so why? If not,
why wouldn't we prefer a solution that limits processing these events?
-Mike-
Rich Thompson wrote:
My suggestion was meant to be quite
a bit simpler than this, something along the lines of:
wsrp:newUserInteractionSet: This is
a Consumer generated event which informs the Portlet that Consumer
policy
has determined that a new set of End-User interactions are starting
(e.g.
the nature of how the End-User has navigated is causing the Consumer to
reset any transiently managed navigational state). The Consumer SHOULD
treat Portlets which handle this event as managing a portion of their
navigationalState
internally and Portlets which indicate they handle this event MUST
reset
any internally managed extension to navigationalState upon receipt of
this
event. As a signal, this event carries no payload, but for
extensibility
does use an open content model.
wsrp:updateNavigationalContext: This
is a Consumer generated event which informs the Portlet that the
Consumer
is building a URL which the End-User MAY store for later activation
(e.g.
as a bookmark). Upon receiving this event, Portlets SHOULD update and
return
a NavigationalContext to the Consumer which enables later activation of
the URL to cause the Portlet to generate markup closely approximating
what
is currently being generated for the End-User. As a signal, this event
carries no payload, but for extensibility does use an open content
model.
The simplicity of this approach
arises
from the Consumer always treating Portlets which handle these events as
having dirty navState (outside of immediately after sending one of
these
events). Effectively the two available operations the Consumer can
trigger
are resetting and flushing into navState the Portlet managed extension
of navState.
Rich
It was suggested last week that we consider using
a predefined consumer
event to manage resyncing navigational state that can't be propagated
in
a getResource response. I was tasked with fleshing out a proposal
based
on this. I think something like this could work -- does anyone like
this better then the lifecycle/bookmark id proposal?:
define a new response field in the resource response called:
[O] boolean navigationalContextDirty;
navigationalContextDirty: this boolean flag indicates whether this
getResource operation resulted in the portlet making a delta to its
navigationalContext that should become reflected in the
navigationalContext before processing the next client request (that
relies on the current navigationalContext). The default is false.
wsrp:updateNavigationalContext:
This is a consumer generated event sent to all portlets that returned a
navigationalContextDirty flag equal to true on a prior getResource
operation. This event must be sent only if the opaque portion of
the
NavigationalContext in the current request is identical to the opaque
portion of the NavigationalContext of the client getResource request
that resulted in the navigationalContextDirty flag being set to true.
If the states aren't identical then the
wsrp:removeNavigationalContextDelta event is sent instead. In either
case the end result is to remove the consumer notion that the context
is
dirty. This event will only be sent on the next client request that
would result in either a PBI, HE, GM invocation meeting the above
requirements (even if such request isn't directly targeted at this
portlet).
wsrp:removeNavigationalContextDelta
This consumer generated event is sent to all portlets that returned a
navigationalContextDirty flag equal to true on a prior getResource
operation. This event must be sent only if the opaque portion of
the
NavigationalContext in the current request is not identical to the
opaque portion of the NavigationalContext of the client getResource
request that resulted in the navigationalContextDirty flag being set to
true. (Otherwise the wsrp:updateNavigationalContext event is sent).
After sending the event the consumer notion that the context is dirty
is
removed. This event will only be sent on the next client request
that
would result in either a PBI, HE, GM invocation meeting the above
requirements (even if such request isn't directly targeted at this
portlet).
FYI ... another aspect of this issue which we haven't yet discussed is
the behavior of the public portion of the navigationalContext when it
changes as a result of a getResource. Right now because we are leaning
to a resoluttion that prevents this from changing in a getResource any
ajax logic that relies on getResource can't be coordinated with other
portlets on the page. Until we can satisfy ourselves that JSF, .NET,
and other like view technologies that will have native components which
use Ajax can without mods to their code run in Subbu's in protocol
mechanism I fear this restriction will be too extreme. For example Ajax
code that is invoked when one selects a customer id (to drill/expand
customer info within the portlet view) couldn't be propogated to other
portlets. For 2.0 I would be willing to exclude this use case as
long
as we realize we likely will need to rework getResource if we find that
the above view technologies aren't seemlessly adapted to our in
protocol
mechanism.
-Mike-
|