Re: [wsrp-interfaces] Groups - Interfaces concall modified - howto solve setting new nav state for gR

[Stefan Hepper <sthepper@hursley.ibm.com>]

Subbu Allamaraju wrote:
> Stefan Hepper wrote:
>> sorry that I missed this call due to my vacation, but I don't quite 
>> understand the minutes.
>>
>> Why wouldn't it solve the problem if the portlet could migrate its 
>> locally managed navState back to the consumer managed navState?
>>
>> Has a solution been discussed that would allow the portlet to 
>> explicitly set the new navState via a script function?
>> How about something like this:
>> - the portlet issues several XHR requests via gR links to update 
>> different parts of its window
>> - at the end the portlet sets its new navState by calling a 
>> pre-defined script method that the consumer provides (e.g. 
>> setNavigationalState) and now the consumer is free to provide an 
>> implementation that stores the new nav state wherever it thinks is 
>> appropriate (URLs, cookie, form fields, ...)
> 
> But this state also needs to be reflected in the consumer too - not just 
> the browser. Moreover, in producer containers, I don't expect portlets 
> to worry about encoding nav state leave alone updating.
> 

The script could also trigger a XHR call to the consumer and tell him 
the updated nav state, right?
I don't quite follow what you are saying in your second sentence, can 
you please explain this a bit more?

Stefan

> Subbu
> 
>>
>>
>> Stefan
>>
>>
>> Michael.Freedman@oracle.com wrote:
>>> Interfaces concall has been modified by Mr Michael Freedman
>>>
>>> Date:  Thursday, 24 August 2006
>>> Time:  11:00am - 12:30pm ET
>>>
>>> Event Description:
>>> 1-888-967-2253 or +44 118 924 9000 (Europe)
>>> meeting ID: 345337
>>> passcode: 060606
>>>
>>> Agenda:
>>> 1) Discuss using events to manage navState/lifecyle when getResource 
>>> is involved.
>>>
>>> Minutes:
>>> Proposed resolution:
>>> Define a single event the consumer can send to the producer to 
>>> indicate that a NavigationalState scope transition is occuring.  All 
>>> other potential features such as sending an event to form a 
>>> bookmarkableURL or providing for more efficient control via producer 
>>> setting a dirty falg should/can be considered as extensions/3.0.
>>>
>>> Open issues:
>>> 1) We have a preference of providing some guidanace (a basic 
>>> definition of) NavigationalState scope to encourage implementations 
>>> beyond the null policy but couldn't express something consisely.  Is 
>>> there a consise definition?
>>> 2) What is the name of the event?  In choosing the name we will have 
>>> to make sure to define the meaning of returning navigationalContext 
>>> from the HE that receives this event makes sense.
>>>
>>>
>>> Highlights of the discussion:
>>> 1) The group is still split on whether its appropriate for us to 
>>> address these problems.  A representative group thinks that 
>>> getResource shouldn't change NavContext in a way that results in the 
>>> need for a new reference.  I.e. they should only manage (at best) 
>>> deltas.
>>> 2) There are strong opinions that we shouldn't have overally strong 
>>> conformance statements (i.e. ensure more standard consumer behavior 
>>> which the producer can count on).
>>> 3) Giving the producer an opportunity to migrate any navState managed 
>>> by reference into the navState itself (by value) may be useful but 
>>> seems secondary to the problem we are trying to address.  We feel its 
>>> somethign that can be separated and potentially added independently 
>>> (as an extension).
>>> 4) The two opinions that were expressed concerning naming the event 
>>> was for wsrp-removeNavigationalContext(Delta).  A consequence of 
>>> choosing this name is that the consumer would be instructed to 
>>> ignore/discard any navContext returned by the HE that received this 
>>> event.
>>>
>>> View event details:
>>> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419 
>>>
>>>
>>> PLEASE NOTE:  If the above link does not work for you, your email
>>> application may be breaking the link into two pieces.  You may be 
>>> able to
>>> copy and paste the entire link address into the address field of your 
>>> web
>>> browser.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> BEGIN:VCALENDAR
>>> METHOD:PUBLISH
>>> VERSION:2.0
>>> PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
>>> X-WR-CALNAME:My Calendar
>>> BEGIN:VEVENT
>>> CATEGORIES:MEETING
>>> STATUS:TENTATIVE
>>> DTSTAMP:20060824T000000Z
>>> DTSTART:20060824T150000Z
>>> DTEND:20060824T163000Z
>>> SEQUENCE:4
>>> SUMMARY:Interfaces concall
>>> DESCRIPTION:1-888-967-2253 or +44 118 924 9000 (Europe)\nmeeting ID:
>>>   345337\npasscode: 060606\n\nGroup: WSRP Interfaces SC\nCreator: Rich
>>>   Thompson
>>> URL:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419 
>>>
>>> UID:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419 
>>>
>>> END:VEVENT
>>> END:VCALENDAR
>>
>>
> 
> _______________________________________________________________________
> 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.
> 
>