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: Public review comment: NavState semantics with respect to getResource


The semantics of how consumers manage navigationalState with respect to 
getResource aren't clearly specified.  What is it we intend?  The 
question is do we intend the consumer to treat getResource navState like 
getMarkup navState or differently?
With getMarkup, the navState encoded in the renderURL becomes the new 
navigational state for the portlet when the renderURL is invoked.  Does 
the same thing happen for a getResource or does the consumer treat this 
NavState as something that is particular to the getResource call but 
unrelated to the general portlet context?  I.e. the consumer retained 
navState for this portlet remains as whatever it currently was prior to 
this getResource call?  If the first case is true then navState is an 
inappropriate place to encode resource specific state as this would 
become part of the overall portlets navigational state.  In this case 
where would one encode such resource specific state?  Should we add a 
new token resourceState much like interactionState on actionURLs?  Or 
should we recommend that this information merely be encoded in the 
resourceId the resource writes into the resource URL?
     -Mike-


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