MutableNavigationalState Allows changing the PortletMode and/or WindowState of a PortletWindow state.
This interface extends the {@link NavigationState} interface to cleanly define the immutable contract of the latter.
Note: this is actually an ugly hack into the Portal as formally (per the portlet specs) the PortletMode and/or WindowState are only to be modified *and* then retained for the *next* subsequent renderRequest.
This interface is used for support of the Pluto required PortalActionProvider implementation (which definition is not undisputed, see: [todo: link to pluto-dev "Why PortalActionProvider?" mail discussion]).
Furthermore, this interface is also used by the Jetspeed-1 JetspeedFusionPortlet to synchronize the NavigationalState. Under which conditions that is done isn't clear yet (to me) but possibly that can/should be done differently also.
Modifying the Navigational State *during* a renderRequest (before the actual) rendering can result in a lost of these new states on a subsequent refresh of the Portlet if that doesn't trigger changing them again, because the state of these changes is only saved in PortletURLs created during the renderRequest, *not* in the session (if SessionNavigationalState is used). The session state has already been synchronized (if done) *before* these methods can be called.
Modifying the Navigational State *during* an actionRequest, as done by Pluto through the PortalActionProvider interface just before it sends a redirect, is kinda strange as it can more cleanly be done through the its PortalURLProvider interface (see above link to the mail discussion about this).
@author
Ate Douma
@version $Id: MutableNavigationalState.java 554926 2007-07-10 13:12:26Z ate $