Re: [wsrp-coord] Issue #07 Predefined events

[Rich Thompson <richt2@us.ibm.com>]

Comments on the points raised:
a. The semantics are already pretty
clear that the Consumer may generate events itself (see 3.10). I would
think that any predefined events we define would simply be for the benefit
of portlets being able to specify their interest in a Consumer-independent
manner and would not in any way restrict Consumers from generating other
events.

b. How would each of the proposed events
be distributed?
 - WindowStateChanged/ModeChanged:
Are these just being sent to the portlet affected? 
        If so, would
such an event have to be queued when a url specifies invoking pbia and
requests one of these changed (spec requires that the Consumer do the change
before invoking pbia)? Is there much value to this case (the portlet already
gets the new mode, just no indication that this is different than last
time)?
        If not,
how would the portlet affected be indicated to the target portlet? How
difficult would be handling the security issues of exposing portlets to
each other?
- Refreshed: Would this be defined to
be when the same navState, mode and windowState are being reused? What
is the difference between this and supplying the validateTag?
- Visible/Invisible: Isn't this just
a special case of the mode changing?

Rich

Subbu Allamaraju <subbu@bea.com>

10/21/2004 06:04 PM

To	wsrp-coord@lists.oasis-open.org
cc
Subject	[wsrp-coord] Issue #07 Predefined events

Several months ago, I raised the question of predefined
events. Here is 
a use case and a proposal, for your review and comments.

Regards,

Subbu

=========================================================

Use Case:

This is a UI-centric use case.

There is an email app consisting of three portlets (a) Folder View, (b)
List View, and (c) Message View. Folder View displays folders, List View
displays list of messages in a given folder, and Message View displays
a 
message.

The UI requirement is that when the Message View portlet is set to 
"full" window state, the List View should be minimized, and vice
versa.

Solution:

a. (Optional) Message View portlet indicates that it can raise a 
WindowStateChanged with name "myurn:full.

b. List View portlet indicates that it would like to receive 
WindowStateChanged event with name "myurn:full".

c. User changes the window state of Message View portlet to full.

d. The Consumer creates and dispatches a WindowStateChanged event 
"myurn:full".

e. The List View portlet then changes its state to wsrp:minimized.

(The event should possibly include some info of the source portlet, but
that comes under Issue #15 - but in the absence of the source info, 
these portlets can choose to name their events to include some source info).

Proposal:

My proposal consists of two parts:

a. Update the semantics to allow Consumers to create and dispatch 
arbitrary events (not limited to predefined events below).

b. Specify some predefined events

I can think of the following predefined events:

a. WindowStateChanged: Raised when the window state of a portlet changes.

b. ModeChanged: Raised when the mode of a portlet changes

c. Refreshed: Raised when a portlet is refreshed

d. Visible: Raised when a portlet became visible (i.e., included in the
same aggregated page)

e. Invisible: Raised when a portlet became invisible (i.e., not included
in the same aggregated page)

As we make progress, we can take the question of concrete scehema types,
event names and types (and their payloads, if any).


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.