Ajax, getResource, and navState

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

I sent a public review comment today to the overall wsrp committee regarding our navState semantics with respect to getResource.  This relates to our Ajax discussion because I am trying to determine how one can use Ajax to implement a portlet (bridge) where the main portlet logic runs entirely in getResource.  Here is the scneario:

A portlet is developed that bridges to an existing web application execution environment.  Its purpose is to wrap and present this web application as a portlet.  The web application is isolated from the fact that its being presented as a portlet (i.e. it doesn't support portlet modes (other then view) and doesn't support personalizations.  Because this portlet bridge wants to provide a single phase/request model to the web application execution environment ( its regular invocation style) it decides to circumvent the wsrp model by causing the bulk of its behavior to be implemented/managed in getResource.  It does this by relying on Ajax:

• phase 1: portlet receives a getMarkup request.  The portlet responds by emitting a <div> tag and Ajax code that will be invoked onLoad to call its getResource with a resourceId that tells it (how) to call the web applications entry point.
• phase 2: markup is returned to the client, the onLoad is executed and the getResource is called.
• phase 3: the getResource uses the resourceId to identify what resource in the web application to invoke and invokes it.  URLs written by this web application (resource) are cast once again the Ajax/getResource model
• ... and so it goes with Ajax/getResource getting called directly when the user interacts with the portlet by clicking on a link in its markup or indirectly via a getMarkup (back to phase 1) when the consumer re-renders the portlet as a consequence of an interaction in another portlet (or for some other reason).

In such an environment, because getResource is replacing getMarkup (rather then augmenting it)  the bridge portlet wants to ensure that the current resourceId (and state) is used whether a regular getResource call is made or the bridge's getMarkup is called because the user has interacted with something else on the page.  This requires the bridge maintain state to hold the "current resourceId/state" so that it can be referenced in this second scenario that getMarkup is invoked.  The bridge portlet has two choices: maintain this state in the portlet session or in navigationalState.  Note: The blended case where  navState is used  to reference session state is considered a refinement of the navigationalState mechanism not the portlet session one.

Because the navigational state mechanism yields cleaner semantics (it handles cases where the getMarkup call isn't in context with the current page such as a bookmarked url or page navigation/return) the bridge portlet prefers this solution.

How do the navigationalState semantics we define for getResource support/hinder the above solution?  I would argue that the portlet needs use to define navState semantics equivalent to getMarkup to support this.
    -Mike-