Re: [wsrp] Navigation params comments

[Subbu Allamaraju <subbu@bea.com>]

Attached my comments.

Subbu

Rich Thompson wrote:
> 
> 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 <michael.freedman@oracle.com>*
> 
> 12/15/05 04:23 PM
> 
> 	
> To
> 	OASIS WSRP TC <wsrp@lists.oasis-open.org>
> 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 **_<subbu@bea.com>_* <mailto:subbu@bea.com>
> 
> 12/14/05 03:06 PM
> 
> 	
> To
> 	OASIS WSRP TC _<wsrp@lists.oasis-open.org>_ 
> <mailto:wsrp@lists.oasis-open.org>
> 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_
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> 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

newAppendicies.doc