Interfaces discussion related getResource/navState

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

 Have updated the wiki replying to Rich's comment on how a portlet can 
deal with maintaining navState in session.  This part of the discussion 
is what I currently see as the main sticking point to accepting the 
proposed solution that navState remain constant during getResource 
calls.  As some of the discussion on the wiki is back and forth here is 
asummary of the issue.

A portlet uses getResource to either in part or as a whole render the 
portlet.  Some of these resource requests impact portlet state.  Portlet 
state (as with the proposed solution) must be maintained in a portlet 
session.  The portlet wants to use this current portlet state to render 
via subsequent getResource calls and/or subsequent getMarkup calls (in 
the case the page is refreshed or the user interacts with another 
portlet on the page and the consumer decides to rerender everything on 
the page).  However, the portlet doesn't want to use this state if the 
user is coming into the page (again) via a bookmark.  Likewise it 
doesn't want to use this state if the consumer policy is that page 
navigation (from/back to this page) should revert the page to its 
default/original state.

The issue is how does the portlet detect whether a given getMarkup (or 
getResource) request is in the current page lifecycle or not?  We 
discussed this lifecycle issue sometime back and decided the lifecycle 
really corresponded to an action lifecycle.  I.e. a new lifecycle begins 
when an action occurs and last until either the next action or the 
consumer policy decides that a certain navigation creates a new 
lifecycle (i.e. selecting a bookmark, navigate from/to the page).  In 
the end we decided not to formailze this lifecycle in the spec because 
we felt the producer/portlet could easily manage its own notion which 
corresponded to this.  However the mechanism relied on encoding info in 
the navState.  Hence the issue with getResource -- for if its precluded 
from using navState it must either resort an obscure and maybe not even 
valid manipulation via client side javascript (Rich's suggestion).  The 
issues for me are:
1) Is there a technical solution so the portlet can implement its own 
notion of lifecycle?
2) If there is, how obscure/feasible is it?
3) What would the spec need to do to directly support a notion of 
lifecycle and what burden would this place on the consumer?
4) Which is better (2) or (3)?

As for what we could do in the spec, I wonder if we can get away with 
asking the consumer to send an actionLifecyleId in all requests and 
define a reserved value to mean the initial/default lifecycle.
    -Mike-