Looks good to me. I think that makes it very
clear.
-Mike
From: Rich Thompson [mailto:]
Sent: Monday, January 09, 2006 1:40 PM
To: OASIS WSRP
TC
Subject: Re: [wsrp] Navigation params comments
I like the idea of adding a table
describing the different types of state. I think another describing the
different coordination mechanisms would also be useful. I have made a start on
two such appendices (I think an appendix is the right place as it is really
commentary on a particular portion of the spec rather than definitional.
Thoughts? comments?
Rich
Michael Freedman
<>
12/15/05 04:23 PM
To
OASIS WSRP TC
<>
cc
Subject
Re: [wsrp] Navigation params
comments
Rich,
Yes, we should clarify its use. I just finished a
conversation with some folks in my development team where they completely missed
needing to use navigational parameters as inputs to internal state. Rather
they equated them more with the current navigational state concept which holds
state. One of the developers suggested providing a table that includes all
the mechanisms and lists such factors as whether it represents managed state or
not, whether its for interportlet comm or not, etc.
-Mike-
Rich Thompson wrote:
By the way, sections numbers are always handy ... your page 29
resolves to section 5.1.17 on page 30 for me.
My comments:
a. The TC decided that "it is always a Consumer choice to supply them
(navigationParameters) on a particular invocation". The direct fallout of this is that the
navigationParameterDescription is not allowed to require supplying if a
particular item. This results in a model where the Consumer only supplies new
values when they occur and the Portlet. Perhaps what is missing is a more
concrete description (both here and in 6.1.11) that navigationParameters are
simply an input which the Portlet SHOULD then store in its navigational
state.
b. This
sentence is providing guidance about how navigationParameters are shared between
portlets, but is explicitly noting that the guidance likely doesn't apply when
two portlets customized from the same POP within the sharing scope (likely the
page).
Rich
Subbu Allamaraju
<>
12/14/05 03:06 PM
To
OASIS WSRP TC <>
cc
Subject
[wsrp] Navigation params
comments
Two questions/comments on the
navigationParameterDescriptions (page 29
of draft 12):
a. There is a
statement that says that
"As such, regardless of the values in the
PropertyDescription‘s
capabilities field, navigationParameters are always
modifiable and
optional."
Does not this weaken the notion of
wsrp:required capability?
b. The intent of the next sentence is not clear
to me.
"While Consumer policy governs what navigation parameters are
supplied
to each invocation of a Portlet, Consumers SHOULD supply the same
value
to Portlets which are related to distinct Producer offered portlet
handles and provide a navigationParameterDescription referencing the
same QName for the parameter’s name."
I think what we want to say is
that the consumer should try to supply
the same value to any portlet with a
matching name as specified in
navigationParameterDescription. How about
changing this text to the
following?
"While Consumer policy governs
what navigation parameters are supplied
to each invocation of a Portlet,
Consumers SHOULD supply the same value
to any portlet with the same QName
for the parameter's name as specified
in the portlet's
navigationParameterDescription."
Subbu
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
