[wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"

[Michael Freedman <Michael.Freedman@oracle.com>]

Title:

Folks,
    A long time ago we decided that the portlet would be responsible for
rendering/managing the buttons commonly displayed in modal MODEs.  For example
the portlet renders the "APPLY", "OK", "CANCEL" button in Edit Mode.  Likewise
the portlet renders the "DONE" button in Help mode.  Unfortunately, our specification
doesn't define how a portlet can accomplish this in ways that meet [what
I consider] basic requirements.  Namely, the specification doesn't define
a uniform way for portlets to recognize what Mode the portlet should return
to when "OK", "CANCEL", or "DONE" are invoked.  Also the specification doesn't
define a uniform way for portlets to use controls/labels that are consistent
with the portal/consumer they are running in.  I feel we must address these
deficiencies in 1.0.  
     These are the basic requirements I believe we must meet:

Requirements related to managing navigation:

MUST requirements:

1) The specification must describe/define a single mechanism that allows
any portlet [session-based or otherwise] to implement "Done" semantics.
"Done" semantics are the ability to optionally accept/process inputed data in a
mode other then VIEW and then to exit that mode; generally by returning
to the mode from whence the portlet came.

2) For portlets using the mechanism defined in (1), the portal MUST be
able to establish a uniform navigational look and feel. I.e. users expect portlets in a given consumer to navigate in a consistent manner.

3) The mechanism defined in (1) must allow allow a return to modes other
then VIEW. For example, it must be possible for a portal to indicate that a portlet that navigates from VIEW to EDIT to HELP will navigate back to EDIT [not VIEW] when the user is done with HELP mode.

4) The mechansim defined in (1) must work for all non-VIEW modes be they custom or defined by the specification.

SHOULD requirements:

1) The mechanism defined in (1) SHOULD be expressed in our protocol in an
easy and obvious mannner so portlet developers find it convenient.

2) A portlet SHOULD be able to ignore the mechanism defined by (1) and
implement semantics of its choosing [limited by other constraints
imposed by the portal/container within the bounds of the specification].  I.e. though we encourage portlets to code themselves using the proscribed technique, portlets should be able to do otherwise at a loss of user interface consistency.

Requirements related to the look/feel of the buttons

MUST requirements:

1) The mechanism we define for rendering mode control buttons MUST allow the portal to maintain a uniform look and feel for these controls across all portlets it manages.

2) The mechanism we define for rendering mode control buttons MUST allow the portal to control the number of buttons/types of operations to be used in a given Mode.  I.e. we mustn't require EDIT mode have a 'OK', 'APPLY', and 'CANCEL' button.  A portal may have choosen a different combination of these.

3) The mechanism we define for rendering mode control buttons MUST allow the portal to maintain a uniform labeling of these controls [across locales] across all portlets it manages.

SHOULD requirements:

1) The mechanism defined in (1) SHOULD be expressed in our protocol in an
easy and obvious mannner so portlet developers find it convenient.

The navigational issue is reflected in Change Request #141: Add previous
window state and mode.  I will request Rich open a new change request for
the button/control management.

On the navigational issue: [Change Request #141]:
I originally introduced this as a JSR related issue as we first re-identified
it in the JSR EG.  Unfortunately, we [the JSR EG] is having a hard time deciding
which of the possible mechanisms available to us we should use to resolve
this issue. As this is an issue that is equally germane to us, I suggest
we tackle this head on without waiting for JSR to make further progress.
 In the end our resolution will likely help JSR come to a conclusion.  To
get started, I suggest we first discuss/approve the requirements our solution
should meet.  Once there is agreement on this 1 to N options can be considered
for approval based on these requirements.  To get the ball rolling, I will
send out another e-mail with 2 distinct solutions that meet the above requirements.

On the button look/feel issue:
I seem to recall we proposed this would/could be solved using CSS.  Unfortuantely,
I am not versed well enough in CSS to propose a solution.  Should we get
started by discussing/approving a set or requirements and then pass these
on to the Markup subcommittee [or an individual volunteer] to make proposal(s)?
     -Mike-