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

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

I don't understand the complication which causes you to choose your 
design.  Why isn't handling previousMode/WS the same as handling current 
mode/WS by the consumer?  It doesn't seem to add any burden/work beyond 
what we have already defined.  Plus it has the advantage of greater 
cacheability -- if the producer must encode this information in the 
navigational state then havign different previous states in the 
Navigational State would cause cache misses even though the rest of the 
MarkupParams is identical.  By having the consumer manage/pass this 
information in the RuntimeContext the previous state doesn't impact 
caching.  My final argument for the JSR approach vs. your is simplicity 
to the portlet developer.  In your design the portlet developer [that 
encodes this info in its NavState] must choose between the previous 
State passed by the consumer [if non-null] or one it carries in its 
navigational state.  This seems a little clumsy and could be 
misunderstood by the developers.  To have one place to get the previous 
state from seems easier/more straightforward for the developer [ala 
getting the current mode/WS].
      -Mike-
     -Mike-

Rich Thompson wrote:

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