Issue #6 Discussion - Wouldn't EventDescription[] be a better type for handledEvents?

["Goldstein, Scott" <Scott.Goldstein@vignette.com>]

In the current draft of the 2.0 specification, the portlet declares, through the PortletDescription, which events it can receive.  This information is currently passed as an array of QName elements representing the array of names of the events that it understands.  The problem with this choice of data type, is that it doesn’t handle the following use case very well:

 

Suppose that there are three portlets on separate producers that have the following event characteristics:

1. Portlet A – Sends an event with name, “ns1:CurrentZipCode”, with the event data type, xsd:string.
2. Portlet B1 – Receives an event with name, “ns2:MyZipCode”, with the event data type, xsd:string.
3. Portlet B2 – Recieves an event with name, “ns3:TheZip”, with event data type, ns3:ZipType

 

The Consumer provides the admin a screen to map sent events to received events.  The admin maps the sent event from Portlet A to be received by both portlet B1 and B2.  He/She does this, because all that a portlet provides when stating which events it receives is the name of the event.  Because the names look similar, he/she assumes it’s okay.  When the event is sent, however, an error occurs because there’s a data type mismatch between what Portlet A sends and what Portlet B1 receives. 

 

Another aspect of this problem, is that two events may have the same datatype and similar names, but may have different purposes.  In this case, it would be useful to have a description in the handleEvents structure to provide a better idea of what the portlet is expecting. 

 

The proposal is to change the handledEvents field to an array of EventDescription’s:

 

Advnatages:

1. Facilitates event mapping on the consumer side

 

Disadvantages:

1. This would introduce an additonal QName within the handleEvents element for the event payload datatype.  If it’s a standard xsd type, this won’t be a concern.  However, if it’s not a standard xsd type, it will require the producer to include the schema for the data type. 
2. The added data type information causes wildcards to be a bit awkward.  Some possible solutions would be:
1. Accepting it
2. Making the Data Type field of EventDescription optional

 

In my opinion, I think the disadvantages are worth the enhanced consumer application functionality.

 

Any other opinions/comments?

 

Scott