Re: [wsrp-wsia] [change request #141] Add previous window state andmode

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

The difference between these is the previousMode while staying within any 
one particular mode. I did not want to require the Consumer to remember 
the previousMode and therefore this is only supplied on the invocation 
where it changed. I presume the use case for continuously supplying it 
relates to generating links that return to the previous mode without any 
requirement that the Portlet remember what the previous mode was. I'm not 
sure this is a good tradeoff as it requires the Consumer to store this 
data as a benefit for a set of Portlets that could easily store it 
themselves (e.g. navState). Producers wishing to provide this storage as a 
convenience to the Portlets they host could also do so without the 
Consumer continuously resupplying it.

Rich Thompson




Michael Freedman <Michael.Freedman@oracle.com>
02/12/2003 02:00 PM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        Re: [wsrp-wsia] [change request #141] Add previous 
window state and mode


The semantics we decided on during the JSR F2F is:
     a) pervious mode does not stack -- its more like simple undo -- your 
new previous mode is the current mode when a mdoe change is requested. 
Stack behavior would have to be implemented/manaegd explicitly by the 
portlet.
      b) Initial state for previous mode/window state is null.
      c) Your previous mode/state stays the same while interacting within 
the page [aggregatable context that contains the portlet] until the 
mode/state changes.
      d) The specification will make no demands for maintaining this 
information once you leaev the page [aggregatable context].  I.e. no 
requirement this is saved when moving from one page to another and back 
again.

Using these rules your example would be:
 1. view first page, mode=normal[commonly -- though up to consumer], 
previousMode=null
 2. transition to help, mode=help, previousMode=normal
 3. navigation within help, mode=help, previousMode=normal
 4. transition out of help, mode=normal [if use previous mode to set 
this], previousMode=help


Rich Thompson wrote:
Document: Spec
Section:  6.1.2
Page/Line: 26/46
Requested by: Mike Freedman
Old text:
New text: [R] string previousWindowState
          [R] string previousMode
Reasoning: We don't give the portlet any ability to affect the URLs the 
consumer renders in the portlet decoration to transfer to new modes/window 

states.  However, once entering such a state via the decoration consumers 
sometimes want to render links to revert to the window state/mode that got 

them there.  I.e. from edit mode to help mode back to edit mode when done. 

 We currently leave managing this previous information as an exercise to 
the portlet developer -- most likely expecting they will encode in 
navigational state or session state -- however this doesn't cover the 
initial portlet state/render.  I.e. when a portal renders a page for the 
first time there is no portlet navigational state -- if a user clicks a 
decoration link at this point then there is no way for the portlet to pass 

"previous" information to itself [via NS].  The world would be a 
simpler/better place [given that we don't open up access to decoration 
links] if the consumer managed/passed this previous information on 
request.  Its in the RuntimeContext as it shouldn't be part of the cache 
key.   Note: for those of you with a long memory -- these fields were 
originally in the specification because JSR 168 had them.  JSR 168 removed 

them hence we dropped them.  In the last JSR 168 F2F we identified the 
problem above and realized we were wrong to drop them.  Carrying this 
information not only gives us "correct" semantics but keeps us in sync 
with JSR 168.

[RT] I remember two significant concerns that caused us to drop these: 1) 
Is this some sort of stack that the Consumer has to maintain so that a 
transition back to the previous window state or mode then exposes the one 
prior to that as the new previous?, and 2) What is the value for the first 

getMarkup() (i.e there is no previous)? I think the problem the JSR 
identified is also significant. Would reintroducing these with the 
semantics that they only have a value when a transition has occured be 
acceptable? This would result in the following (for mode):
 1. view first page, mode=normal, previousMode=null
 2. transition to help, mode=help, previousMode=normal
 3. navigation within help, mode=help, previousMode=null
 4. transition out of help, mode=normal, previousMode=help

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>