[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] [change request #141] Add previous window state and mode
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC