OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Groups - Interfaces concall modified - how to solvesetting new nav state for gR



I also missed this call due to vacation ...

How the browser-side Consumer components communicate with the server-side Consumer components is a Consumer implementation issue.

However, in the general case, availability of script can not be counted on. While a roundtrip through the browser may be a good path for the emerging AJAX use case, the core solution should not depend of this. Having the core solution provide the means for the Portlet/Producer to manage this entirely as extended navState with extensions for efficiently pushing it to the Consumer managed navState does have some advantages, especially for this stage of spec development.

Rich



Subbu Allamaraju <subbu@bea.com>

08/29/2006 09:00 AM

To
Stefan Hepper <sthepper@hursley.ibm.com>
cc
wsrp-interfaces@lists.oasis-open.org, wsrp@oasis-open.org
Subject
Re: [wsrp-interfaces] Groups - Interfaces concall modified - how to 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]