Re: [wsrp] GetResource, NavState, and events

[Rich Thompson <richt2@us.ibm.com>]

I agree that they both accomplish the
purpose. Considering the frequency at which I expect these events will
need to be sent, I would favor simplicity over efficiency. 

On your other question, I definitely
favor this approach over the ID approach as it enables the use case while
keeping the issues related to implementing the details primarily within
the party making the choice which causes the issues.

Rich

Michael Freedman <michael.freedman@oracle.com>

08/16/2006 06:13 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] GetResource, NavState, and events

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

Michael Freedman <michael.freedman@oracle.com>

08/15/2006 07:34 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[wsrp] GetResource, NavState, and events

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-