OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Got it.

I don't think the getResource operation is designed for this use case. 
We have agreed that resource serving is semantically independent of 
other markup operations, and the current framework does not allow the 
consumer to allow nav state changes to be reflected during full page 
renders. This issue calls out for a full-fledged solution at the 
protocol level.

Subbu


Michael Freedman wrote:
> In general we wouldn't require the consumer to support bookmarking a 
> page in the middle of one of these portlets. In general, you can only 
> bookmark from points in which the whole page is rendered. This scheme 
> however does ask us to consider how to enable such subsequent full page 
> renders to be the equivalent of the current resource/navState.
>    -Mike-
> 
> Subbu Allamaraju wrote:
> 
>> 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.
> 

_______________________________________________________________________
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]