Agree to the extend that they are muddied already
but:
Nav state can optionally be throw away (so
portlet defaults to initial view)
Nav state is per user view (while a
consumer can select how portlet state is shared)
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 12 September 2005 12:39
To:
wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces]
Implementation question
I may be misunderstanding, but wouldn't this
significantly muddy the waters between navState and portletState?
Rich
|
"Andre Kramer"
<andre.kramer@eu.citrix.com>
09/12/05 05:20 AM
|
|
To
|
"Michael Freedman"
<michael.freedman@oracle.com>,
<wsrp-interfaces@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [wsrp-interfaces] Implementation question
|
|
Yes, nav state could be used to hold long lived
session data that persists across consecutive user logins. I believe a lot of
portlets could utilize a “as last viewed” display e.g. my local
weather, with view state set directly via the UI, as I fly from hot and
impossibly humid, hurricane endangered Florida to grey but safe England.
Regards,
Andre
From: Michael Freedman
[mailto:michael.freedman@oracle.com]
Sent: 06 September 2005 17:52
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Implementation question
We [the Oracle Portal] view navigational state as unrelated to user/session
state. Navigational state is encoded in the URLs on the encapsulating
page. Currently, this is the only attempt/context for maintaining these
URLs -- thus when you navigate to another page and return navigational state is
lost. Users of course always have an option of bookmarking the page with
its current navigational context.
What is the prupose of your "hint"? Is it to allow the consumer
to better manage a navigational state cache if/when it decided to manage such
data internally vs on the URL? If so, in what circumstances would a
portlet indicate anything other then "true" as this gives the closest
semantics of bookmarked navigatinal state? Are you thinking there are
situations where the portlet uses navigational state to hold portlet session
data? If so why do they do this vs using portlet sessions as they can
transfer the management of this opaque state to the consumer as well?
-Mike-
Andre Kramer wrote:
If
I may somewhat abuse
this
forum
for a quick poll on how navigational state is handled in WSRP
consumer implementations, wsrp-interfaces being the
most active / vocal one:
Do
your Portals facilitate saving a WSRP Portlet’s
navigational state between end user login
sessions? I.e. if I navigate to a remote portlet’s
XYZ
screen and then log out from the consumer will I
actually
be
able to log in later (go to the page for the WSRP
Portlet) and see XYZ if the portlet has saved/encoded
“show
XYZ” in its navigational state? I know the spec
supports this but is it widely implemented / selectable?
If
not, do people think this should be supported by a new boolean
flag
in a portlet’s metadata description:
requestingNavStatePersists=true/false?
Also,
I will not be able to make the SC call next week so,
again,
my apologies.
Regards,
Andre