RE: [wsrp-coord] Issue #11: Should we allow Portlets to always beincluded in event / action handling?

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: RE: [wsrp-coord] Issue #11: Should we allow Portlets to always beincluded in event / action handling?

Well, the "click counter" was the base use case. I agree that this could be addressed using a pre-defined event, but I think we may want to step back and develop the big picture.

Incidentally, a use case for reporting faults to portlets is that there are often multiple ways for a user to perform a task and a fall-back choice can then be offered by another portlet on a page, in case of first choice failure (say, if 2nd portlet is at another producer, but only if fault with first choice portlet is reported and if the portlet the fault is reported to can switch from being minimized). At least, an email to the IT service desk can be offered to be sent :-)

The overriding aim for coordination should be to maximize the user experience by flexibly allowing Portlets to react to and coordinate their reaction to user interactions. Personally, I wish we could address "async" inputs, but at least we should offer something significantly better than the "1.0" experience (I hate to see failed portlets rendered on our demo pages).

The basis for coordination is communication and we should maximize possibilities for it. E.g. A page load should allow ECMAScript "headers" to be signaled to the consumer - the list of use cases is potentially long...

Fundamentally, we may have three types of information flowing within the communication. Each type should be raise-able by specified parties (actors: user, consumer, producer or portlet) but only at certain stages of the coordination. (This would argue for "performBlockingInteraction" being an event that can only be raised by the user.)

1) Events - can be raised by consumer and portlets/producers. Can be communicated to all in the coordination, with the chance to react by sending more events.

2) Failures - can be raised by consumers, portlets and producers. These can be raised and reported in the coordination just like events.

3) Render parameters - seem to serve a "portlet" specific need to inject data into the render phase. Why not allow them to be communicated to all parties during the coordination? Why not allow them to be sent between portlets?

Render params are then just special events that should not cause further events to be generated and that get collected and replayed in the render phase. And, with the above, a failure event can be listened for and turned into a render parameter, for example, to change the UI style.

I suspect that we will have standard examples of events, failures and render params to define - otherwise why have them?

Please excuse my lack of focus on the specific issue, but looking over our opening emails, I do not wish to get lost in the trees (portlets?) while wanting to see the forest (portlers coordinating).

Regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 21 October 2004 20:34
To: wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Issue #11: Should we allow Portlets to always beincluded in event / action handling?

Andre,

Can you elaborate, if possible, with a use case? If we want such a
notification to be considered as an interaction, I think we should
discuss if Consumers can create and dispatch some predefined events
(Issue #7). Other than this, I don't see why a given portlet should
always be included in an event/action handling.

Regards,

Subbu

Are you considering that this non
Andre Kramer wrote:
> Some portlets may be specially placed on a page to overview
> coordination. These may like to overview all user interactions (e.g. a
> click counter). User action and page load could be pre-defined consumer
> events that Portlets could subscribe to. [I know we ruled out
> subscription for Portlets but should consider consumer initiated events.]
>
> Regards,
>
> Andre
>

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php.