[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Groups - Interfaces concall modified - howto solve setting new nav state for gR
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. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]