[Fwd: Supporting 'Back' semantics]

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

Title:

 To further motivate why we should allow 'Back' semantics to be passed by
the consumer in our protocol I have forwarded an e-mail I sent to the JSR
168 EG providing example code that shows that without such support the portlet
developer is forced to invent/write their own getBackMode/WS method and hope
their heuristic matches something that makes sense in the portal.

Basically, the example shows that if a consumer/portal doesn't have the means
to express this information directly and it wants to ensure the highest possible
degree of consistency it is forced to manipulate the validModes/WindowStates
to get its desired result.  For example in the situation that a consumer
takes a portlet from VIEW->EDIT->HELP and wants to make sure the portlet
unwinds through the entire stack it would set the validModes to VIEW, EDIT,
and HELP when in EDIT mode but only EDIT and HELP when in HELP mode, thereby
indicating its intent to prevent the hardcoded transition back to VIEW from
HELP.  Because validModes are provisional in WSRP, the portal/consumer will
be forced to detect the inappropriate mode transition on request [from the
portlet] and write code that interpretes the portlets intent.  I.e. if the
portlet is in Help mode as above and asks to return to View mode then I will
interprete this as a request to go to the previous mode, hence put/render
them in Edit mode.  Some guess work is going on here but if the portal carefully
controls its stack/validModes it can do the "right thing" most of the time.
 

Now in the code example, shown in the forwarded message, you will see that
the portlet/producer is forced to do the guessing. This is because though
validModes/WS are provisional in WSRP they are not in JSR 168.  A JSR 168
portlet can't set/request a mode that the portal indicates is invalid.  [If
you think about this, this is very reasonable behavior for a container built
on top of WSRP trying to facilitate portlet development].  In the JSR 168
environment, the portlet tries a preferred 'Back' mode -- generally VIEW.
 But in the cases this fails it writes a heuristic to guess what it should
really go back to.

All in all, I suggest we would be much better off if neither the portlet/producer
or portal/consumer had to do any guessing, hence the change request. 

One aside to remember in all this, is that for most portlets the only Mode
transitions they will code will be 'Back' semantics to return from being
in Edit mode or Help mode which the portal placed them into in the first
place. I.e. most portlets rely on the portal to render links [in the portlet
decoration] to move them into new modes.  [And thereby getting a consistent
UI].   Portlets however are forced to implement the buttons that control
terminating these modes.
 
       -Mike-

-------- Original Message --------

Return-Path:	<jsr-168-redistribution-request@sun.com>
Received:	from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNUjB05190 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 16:30:45 -0700 (MST)
Received:	from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNUio05016 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 16:30:44 -0700 (MST)
Received:	from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUhh11416 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 15:30:43 -0800 (PST)
Received:	from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNUgW11406 for <jsr_168_us@oracle.com>; Wed, 19 Mar 2003 15:30:42 -0800 (PST)
Received:	from sunmail3.sfbay.sun.com ([129.149.247.180]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02266; Wed, 19 Mar 2003 16:30:38 -0700 (MST)
Received:	from nwkea-mail-1.sun.com ([192.18.42.13]) by sunmail3.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2JNUQk15440; Wed, 19 Mar 2003 15:30:26 -0800 (PST)
Received:	from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07535; Wed, 19 Mar 2003 15:30:25 -0800 (PST)
Received:	from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP; Wed, 19 Mar 2003 23:30:11 Z
Received:	from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Wed, 19 Mar 2003 23:26:57 Z
Received:	from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z
Received:	from swjscmail2.java.sun.com (swjscmail2.java.sun.com [192.18.99.108]) by relay11.sun.com with ESMTP; Wed, 19 Mar 2003 23:29:33 Z
Received:	from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id 632C9213C0; Wed, 19 Mar 2003 16:26:01 -0700 (MST)
Received:	from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6140685 for JSR-168-EG@JAVA.SUN.COM; Wed, 19 Mar 2003 16:23:23 -0700
Delivered-To:	jsr-168-eg@jcp.org
Received:	from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by swjscmail1.java.sun.com (Postfix) with ESMTP id 212FE484C for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 16:23:23 -0700 (MST)
Received:	from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.3) with ESMTP id h2JNTUL25408 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 15:29:30 -0800 (PST)
Received:	from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNTTe25391 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 15:29:29 -0800 (PST)
Received:	from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTTm09725 for <JSR-168-EG@JCP.ORG>; Wed, 19 Mar 2003 16:29:29 -0700 (MST)
Received:	from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2JNTSt09709; Wed, 19 Mar 2003 16:29:28 -0700 (MST)
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language:	en-us, en
MIME-Version:	1.0
Content-Type:	text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding:	7bit
Message-Id:	<3E78FC82.4070005@oracle.com>
Date:	Wed, 19 Mar 2003 15:25:54 -0800
Reply-To:	Java Community Process JSR #168 Expert List <JSR-168-EG@JCP.ORG>
Sender:	Java Community Process JSR #168 Expert List <JSR-168-EG@JCP.ORG>
From:	Michael Freedman <Michael.Freedman@oracle.com>
Organization:	Oracle Corporation
Subject:	Supporting 'Back' semantics
Comments:	To: jsr168 <JSR-168-EG@JCP.ORG>
To:	JSR-168-EG@JCP.ORG

Just to make this issue real here is some sample code JSR 168 developers
will have to write to deal with Edit/Help modes.  Shouldn't we find an
easier way for them to write this?  And at the same time give the portal
a little more influence over the result vs. merely manipulating the
valid modes and window states.  I.e. what is the value of forcing every
developer to discover that in the end they need to write the equivalent
of a getBackMode and getBackWindowState?  I think the developer would
prefer our API provide these methods.  If/when we decide to do so, we
should do so in a manner that gives the portal/container to represent
the actual intent of the portal vs. relying on some generic heuristics
related to what modes/states are valid.

Note: all portlets will have to write something like this even if they
are maintaining navigational state themselves as a Portal is allowed to
manage navigation by manipulating the valid WS/Modes.  However, if I
were a portlet that maintained such state [can only be done if I have a
session] then I might use this additional information to affect the
order of my search.

     public void processEdit(ActionRequest request, ActionResponse response)
     throws PortletException
  {
      /* Detect which button was pushed [apply, cancel, ok] */
      if (request.getParameter("apply") != null)
      {
           doApply(request, response);
           return;
      }
      else if (request.getParameter("ok") != null)
      {
           doApply(request, response);
      }

      // On either 'OK' ot 'Cancel' return to previous mode

      .....
      try {
         /* see method below for how getBackMode is implemented */
         response.setPortletMode(getBackMode(request));
      } catch (PortletModeException pme) {
         /* Oops something went wrong with my
            hueristic to get a back mode */
         throw new PortletException(...);
      }

      /* now do the exact same thing for setting the Back window state */
      /* see method below for how getBackMode is implemented */
      try {
         response.setWindowState(getBackWS(request));
      } catch (WindowStateException wse) {
         /* Oops something went wrong with my
            hueristic to get a back mode */
         throw new PortletException(...);
      }
      //
      .....
  }

public PortletMode getBackMode(PortletRequest request)
  {
      // always try and go back to VIEW mode -- if
      // this doesn't work then pick one that isn't the
      // current one.

      if (request.isValidPortletMode(PortletMode.VIEW))
          return PortletMode.VIEW;
      else if (request.isValidPortletMode(PortletMode.EDIT) &&
               !request.getMode().equals(PortletMode.EDIT))
          return PortletMode.EDIT;
      else if (request.isValidPortletMode(PortletMode.HELP) &&
               !request.getMode().equals(PortletMode.HELP))
          return PortletMode.HELP;
      ....
      // have an additional else if clause for each custom
      // mode I recognize.

      // Oops -- fell out so merely use the current mode
      return request.getMode();
  }

public WindowState getBackWindowState(PortletRequest request)
  {
      // always try and go back to NORMAL mode -- if
      // this doesn't work then pick one that isn't the
      // current one.

      if (request.isValidWindowState(WindowState.NORMAL))
          return WindowState.NORMAL;
      else if (request.isValidWindowState(WindowState.MAXIMIZED))
          return WindowState.MAXIMIZED;
      else if (request.isValidWindowState(WindowState.MINIMIZED))
          return WindowState.MINIMIZED;
      ....
      // have an additional else if clause for each custom
      // window state I recognize.

      // Oops -- fell out so merely use the current mode
      return request.getWindowState();
  }

      -Mike-