[Fwd: Supporting 'Back' semantics]

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-