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