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>