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

[Rich Thompson <richt2@us.ibm.com>]

I see several reasonable scenarios:

1. The Portlet is not allowed to encode
navState on a resource URL, but the Consumer is required to supply the
Portlet's current navState. We would likely need to introduce a wsrp-resourceState
portlet url parameter to cover the need to pass additional state to resource
generation.

2. The Portlet is allowed to encode
a navState on a resource URL, but it only applies to the getResource call.

3. The Portlet is allowed to encode
a navState on a resource URL and the Consumer is required to use this as
the Portlet's new navState.

Issues I see:
#3: This basically requires a stateful
Consumer and likely breaks how bookmarks work.
#2: This breaks symmetry with how the
navState portlet url parameter is handled on other url types and would
likely confuse Portlet developers.
#1: This approach would require Portlets
using resource to update a portion of their markup to store/manage a delta
to the most recently set navState.

I'm sure I am missing other possibilities
and issues, but from this set I would prefer #1 as it keeps the locus of
managing the issue with the party who knows what that management needs
to do.

As to Richard's comment about really
needing to replace the MarkupParams and MarkupContext with resource specific
ones, I generally agree though I find it only tangentially related to this
thread (though it has been so related to several other discussion threads
in the past). Richard, would you be willing to submit that as a separate
public review comment so that the discussion is likely to cover the larger
set of issues than just navState?

Rich

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

06/26/06 12:38 PM

To	Michael Freedman <michael.freedman@oracle.com>
cc	wsrp <wsrp@lists.oasis-open.org>
Subject	Re: [wsrp] Public review comment: NavState semantics with respect to getResource

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




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