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

[Michael Freedman <Michael.Freedman@oracle.com>]

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>