Proposal Consumer generated dynamic event wiring UI / event URLs

[Stefan Hepper <sthepper@hursley.ibm.com>]

Hi all,
on the F2F meeting I got the action item to make a proposal for my use
case of creating a dynamic event wiring UI as extension to WSRP 2.0.

Here the use case again:
- a portlet displays contact information about persons (name, email,
phone, etc)
- other portlets accept such person information as event input parameter
- the consumer would like to generate a UI, e.g. popup that would allow
the user to choose to which other portlet this information should be
sent (e.g. the menu can contain things like: add to addressbook, send
email, call)
- after selecting one item of the list the consumer would issue an event
to the target portlet

A similar paradigm is used in the windows explorer with the sendTo popup
menu.


I would like to propose a more general concept that enables this use case:
Create a new URL type for events that triggers directly the handleEvent
interface.

The URL would be constructed like this:
wsrp-type = event
wsrp-name = <QName of the event>
Activation of this URL will result in an invocation of handleEvent. The
consumer is free to distribute this event to other consumers or
portlets. The portlet should therefore be aware that this event call may
be distributed in parallel and thus should not make state changes that
require the blocking action semantic.

If the event payload is submitted via a form it must be transported to
the portlet in the EventParams field as extension wsrp-form-parameters
with type NamedString.
If the event payload is not submitted via a form it must be transported
as query parameter with the name wsrp-payload.

Note: currently the URL type is not extensible, therefore we would need
to add the following in section 10.2.3:
   ConsumerURL = BeginToken (RenderURL | ActionURL | ResourceURL |
Extension) EndToken
   Extension = Text


Comments welcome.

Stefan