GetResource, NavState, and events

[Michael Freedman <michael.freedman@oracle.com>]

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-