[wsrp-wsia] [wsrp][interfaces] Should we get rid of non-blockingactions?

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

Based on feedback from a number of you as well as internal discussions I
have had I would like to propose the following refinements to the state
management model I posted last Friday.  Basically I propose we drop the
notion of non-blocking actions and define that an action always results
in a client redirect albeit in the common case this will be an implicit
redirect.

What am I talking about:  There are a few problems/complexities with
what I suggested last Friday.
    a) We needed to encode action urls with both action state and
navigational state in a manner that allowed the portal to distinguish
between the two.
    b) markupParms defined as lasting only a single render seemed to
break refreshability/bookmarkability of navigational state.

To deal with these problems I suggest we model (more directly) the web
model.  In a web application, the "proper" way to implement
action/transitory state is to have the action handler do a client
redirect back to itself passing the necessary navigational state in the
redirect URL. In this way the action URL is never available for
bookmarking/refreshing -- only the redirect URL.   I suggest we model
this behavior.  We have already said that an action handler can do an
explicit redirect.  This satisfies some of the cases.  However, what the
typical action handler wants to do is redirect back to the page the
portlet is on.  Both because this is the common case and the Portal
already knows the page URL and because the Portlet as of yet has know
knowledge of the page URL, I suggest that the default behavior of an
action handler is defined as upon return the consumer must redirect to
the URL/page the portlet is on.  So that new navigational state can be
conveyed by the action handler for this redirect we have the
performAction return "markupParams".  I.e. markupParams become the
navigational state for implicit redirects.

If we go with this model then we must drop the notion of non-blocking
actions as it only makes sense for a blocking action to do a redirect.
The good thing about dropping non-blocking actions is it makes the
protocol simpler to understand.  Its a little confusing to have an
action handler that runs under different restrictions/behaves
differently based on whether or not its blocking or not.  Also its more
confusing to the developer to understand when they can use one vs. the
other.

So, putting this altogether the writeup I sent on Friday would be
written to reflect the following:
Typically, Navigational state and Action state are represented as query
string parameters in the links a portlet writes in its responses to
getMarkup.  We support two types of links, navigational links and action
links.  A navigational link only contains navigational state.  When a
user clicks on a navigational link only the portlets getMarkUp is
called.  Navigational links are bookmarkable/refreshable, etc.  An
action link contains both navigational state and transient (action)
state.  No distinction is made between these types of parameters on the
URL.  When a user clicks on an action link the portlet's performAction
is called.  All of the parameters on this link, whether representing
navigational state or action state are passed to perform action.  The
result of a perform action is a client redirect either to another action
URL or a navigational URL.  A portlet can explicitly control this
redirect location by setting the redirect URL return parameter.  If no
explicit URL is provided the consumer still performs a redirect; it
redirects to its navigational URL containing the portlet (i.e. the
page).  In both the explicit and implicit redirect case the portlet is
capable of controlling the redirected navigational state by returning
its navigational state as a query string (i.e. in query string format)
in the performActions responses markupParams.  The consumer is
responsible for ensuring these params are attached to the redirect URL
and hence become part of the new navigational state to the subsequent
getMarkup.

All other things I said last Friday with regards to sessions and the
fact that markUpParams are not  returned by getMarkup remain.  One
potential change for simplicity (to the developer) is that markUpParams
aren't passed to getMarkup either.  Rather they aren't distinguished
from any other types of client parameters being passed in the request
and are therefore retrieved from the clientParameters data element in
the RequestContext.

     -Mike-