OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-coord message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.

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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]