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
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 29 Aug 2006 09:39:28 -0400
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]