Re: [wsrp-coord] Event handling operation: Placement and Signature

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

I think we will need to pass a UserContext as well as the current navigationalState.
 We will also need to allow new navigational state, newWindowState, and newMode
to be returned and a new SessionContext and PortletContext -- i.e. just like
UpdateResponse except instead of MarkupContext being returned you can additonally
return other events.  We should discuss whether to allow redirect from an
event or whether we leave this exclusively in the blockingAction.  We also
need to decide on the semantics of redirect from a blockingAction that returns
events.

Depending on the consumer impelmentation the consumer likely doesn't know
whether returning markup is sensible because it doesn't know if the portlet
event handler will return new events that it will need to dispatch other
portlets.  As each call to event handler can result in new portlet navigational
state, many consumers will need/choose to treat the action/event handlers
as a single block followed by requesting renderering [possibly by redirecting
to clear the action state for bookmarkability].  This is so it can properly
 rewrite URLs with all the correct/final navigational states.  This problem
doesn't exist [even once we add events] on blockingActions because an action
knows that if it doesn't return any events its safe to optimize and return
Markup.  However once events are returned all bets are off and I would therefore
prefer not to "trick" developers into thinking they should code themselves
for the off chance a consumer wants to send "true".  Additionally, as I have
suggested we already have to add a lot of clutter to our API so the portlet
can access/return its state.  I prefer not to add the clutter of the MarupParams
information so they can render as well.
     -Mike-

Rich Thompson wrote:
>  
>   
>   Today's conference call came from two different
> directions toward the need for a generic operation via which the Consumer
> would pass events to a Portlet via the Producer. A couple of questions about
> such an operation are: 
>  
>   Placement? It was stated 
> again today that such an operation would need to be in the Markup portType 
> so as to allow proper handling of any cookies used to reference sessions on
> clustered J2EE servers. Any objections to placing the operation in the Markup
> portType? 
>  
>   Signature? The signature 
> previously proposed was: 
>               events[] handleEvents(registrationContext,
> portletContext, runtimeContext, events[]) 
>  
>   Andre mentioned that we might want to include
> an optimization whereby the Consumer could indicate (presumably in runtimeContext)
> that returning markup would be sensible and then also a place in the response
> for a markupContext. Any other comments at this point in the overall discussion?