Re: [wsrp] Public review comment: NavState semantics with respectto getResource

[Subbu Allamaraju <subbu@bea.com>]

Richard Jacob wrote:
> 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).

I agree with your comment that there is some confusion about the 
semantics of various fields due to the reuse. Leaving it as is would 
only increase the confusion further in future causing interop headaches.

Subbu

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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.