Re: [wsrp] Public review comment: NavState semantics with respect togetResource

[Richard Jacob <richard.jacob@de.ibm.com>]

I agree, I think it should be encodeable state particular to that resource.
The main problem/misunderstanding in my opinion is introduced by the reuse
of markupParams and markupResponse.
Perhaps we should really have distinct params&response types here and stuff
only in, what is really needed (see our famous validNewModes discussion).

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Michael Freedman                                              
             <michael.freedman                                             
             @oracle.com>                                               To 
                                       wsrp <wsrp@lists.oasis-open.org>    
             06/14/06 07:30 PM                                          cc 
                                                                           
                                                                   Subject 
                                       [wsrp] 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-

---------------------------------------------------------------------
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