[wsrp-wsia] [change request #141] Add previous window state and mode

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

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