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

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

Title:

Some questions/comments embedded.

Alejandro

Michael Freedman wrote:

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"

What do you mean by modal MODEs?

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;

Why going back to VIEW/NORMAL would not be enough for the DONE
semantics? Wouldn't this cover most (if not all) cases?

When you say "inputed data in a mode other than VIEW" I assume you
refer to modifying properties in EDIT or the DONE woud be used also
when the portlet is doing a trasaction in VIEW?
> > generally by returning to the mode from whence the
> > portlet came. 
If a portlet mode transition is VIEW, EDIT, HELP, EDIT, where the DONE
semantics would take me, back to HELP or to VIEW?
> > 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.
I assume that by "uniform navigational look and feel" you are meaning
"uniform navigational behavior", right?
I don't know how this could be done as the portal has no way to enforce
portlets to provide the set of buttons that should be displayed in the
portlet content. We could certainly make recommendations, but to me
this belongs to a best practices document.
> > 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.
> >   
This is implicitly requiring the consumer to keep a history trace per
portlet.
A portlet can keep track of where to go back in the session or in the
navigational state. The latter would not work when the user is clicking
on the controls (VIEW, EDIT, HELP, NORMAL, MINIMIZE, MAXIMIZE) in the
portlet window title bar, we have to see how (or if) we fix this.

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.

I don't see convenient the fact that a portlet will always have to
check the portletmode and windowstate it will be taken when DONE
semantics is applied. What I'm trying to say is, portlets may decide to
set different navigational state depending on the portletmode and
windowstate they are going. As now it is not the portlet the one
deciding the portletmode or windowstate, the portlet has to check where
the portal will take it and then set the proper navigation state. IMO,
this is an unnecessary complexity forced uppon the developer.
> > 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.
> >   
I wouldn't say this is a SHOULD requirement, portlets can always do
this by just going to a specific portletmode and windowstate.

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.

Yes, I think is a good idea to define CSS classes to be used for
buttons that confirm a task or cancel a task. We could also add (I
think it was proposed in another change request), next-step and
previous-step.
> > 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.
I don't understand why a portal would remove buttons from the portlet
content. That's dangerous, it could break portlet functionality encoded
in those actions (as it is not accessible). 
It would require the portal to parse the portlet content to do. Or it
would require to pass with the markupParameters the list of  buttons
the portlet can use, but still a portlet could create a button not
indicated in the markupParamters.
> > 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.
> >   
It seems like a good idea but I'm not sure if the practical end result
is desirable. Suppose a portlet that always creates English content. It
is invoked by a userAgent that indicates French locale, the portlet in
the portal page would have all its content in English except for the
control button labels that would be in French.

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.

Unless I'm missing something, (1) is about adding a set of CSS classes.
>  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-