[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Issue #45: Signalling State changes in interaction response
There are two areas I would like to explore:
a) how sticky is navigational state?
b) is it really preferrable to interpret not returning
navigational state as meaning reuse existing navigational state?
How sticky is navigational state?
Currently the specification implies its sticky. Navigational
state is provided by the consumer until the portlet explicitly changes
it/removes it. This puts a great burden on the consumer [particularly
those trying to maintain such state in the client]. I.e. consider
the user that is on a page with a portlet with explicit navigational state.
The user then navigates from this page to another page and so on until
some time in the future a navigation is done that leads her back to the
original page. Must the consumer have maintained (and resupply) the
navigational state of the portlet on this subsequent reentry? I hope
not. I suggest we clarify the specification to only mandate that
navigational state is maintained within the context of aggregated whole
[i.e. page]. And the specification be mute on maintaining navigational
state after navigating from this context.
Is it preferrable to interprete not returning navigational state
as meaning reuse existing navigational state?
Currently, if you don't return navigational state from performInteraction,
the consumer continues to use the current navigational state. Likewise,
if you don't set navigational state in a URL [link] the consumer is supposed
to use the current navigational state. I think we should do the reverse.
Navigational state must be explicitly returned/set or else the system reverts
to no navigational state. Here are me reasons:
a) Easier to debug. In the performInteraction case there are cases where new navigational state is very similar to the old navigational state. In this situation if a developers forgets to update the state, it likely to continue to run. The functional problem may not even be noticeable until some further state/navigation. Where if navigational state isn't carried forward if none is set its likely the portlet will not run or if it does run it will be very apparent that something is wrong.b) Coincides better with Producer URL writing semantics. I believe we expect the consumer send a {navigationalState} token in the producer template and the producer must replace it. If this situation requires explicit setting of navigational state shouldn't we do so everywhere to be consistent?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC