Re: [wsrp] Interfaces discussion related getResource/navState

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

Inline.

Subbu Allamaraju wrote:

> These requirements by the portlet to not use its stored in the session 
> in certain cases is counter to the current spec. The current model is 
> that the consumer decides whether to render the portlet in its current 
> state, or the default state.


I agree, that is why I have raised this issue.  I think I must be 
miscommunicating because I am trying to describe a situation when the 
consumer is intending the default state but the producer can't detect 
this and has to use its current state.

>
> AFAIR, we could not come to an agreement in the past on whether the 
> lifecycle ID is required, and if so, the semantics around it. I doubt 
> if we can make progress quickly enough in the WSRP 2.0 time-frame.
>
> Secondly, the approach that the bridge portlet is taking to render 
> itself asynchronously seems trouble-prone, and I doubt if such a 
> bridge portlet could be coded to work correctly.

>
> I would flip the problem to the consumer side doing its aggregation 
> using Ajax. In that case, the bridge portlet would not be using 
> getResource as the primary vehicle for rendering itself. It would use 
> getResource just for resources, which has been the intent in the spec.
>
> I agree that there are not enough handles to solve the problem as 
> stated, but we need to justify if this is the right problem to pursue. 
> The more we discuss about this, the less convinced I am that it is the 
> right problem.

I agree this is an extreme use case but for the problem I raised I don't 
think its unique to it.  getResource allows form data to be submitted 
correct?  Are we intending to tell Ajax developers (using getResource) 
to never use this feature under any circumstances?  Won't most 
situations that rely on such data transmission likely hold onto this 
state -- and as they can't in navState be forced to do so in session 
state?  If so, these use cases exhibit the same problem I have been 
describing.
     -Mike-

>
> Subbu
>
> Michael Freedman wrote:
>
>> 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-
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your TCs 
>> in OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> _______________________________________________________________________
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php