Re: [wsrp-interfaces] Ajax, getResource, and navState

[Subbu Allamaraju <subbu@bea.com>]

In your scenario (leaving aside the semantics issue for a minute), how 
would the consumer manage the navigational state for book-markability sake?

Subbu

Michael Freedman wrote:
> 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-

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.