[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
Meant to say that, in producers that are porltet containers (e.g. a JSR168 container), portlets don't directly deal with opaque nav state. The container does the job of encoding render params into nav state. So, we need to get the container provide some script to be rendered along with the portlet's markup, and this script will have to do the encoding. Subbu >> 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. >> >> > > _______________________________________________________________________ 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]