We have a bunch of requirements about “saving state across navigation”
Legacy tools should not save state
http://bugs.sakaiproject.org/jira/browse/REQ-285
Sakai remembers state – optional?
http://bugs.sakaiproject.org/jira/browse/SAK-737
Sakai Saving State – Moving between tools and within pages of a tool should behave conistently for users.
http://bugs.sakaiproject.org/jira/browse/REQ-37
Basically the use case is simple – every time you move between tools or between sites, the tool that you “come back to” needs to be at its initial screen.
In Sakai 2.2 – when you “come back” you are brought back to where you left and the tool is in the state you left it.
As an example:
Go to resources – press the Add button – Go to Home – Go Back to Resources – what do you see?
In the state saving approach – you are at the Add screen – in the state clearing approach you are at the top of the resources hierarchy as if you pressed Resources for the first time.

This historically has been a hotly debated topic (lets not replay that now – although we might want to discuss it in Atlanta). The two points of view basically are this (1) advanced users *really* like the ability to pop back and forth between things and take a quick look at another tool while in the middle of something in their main too and (2) this confuses the HECK out of beginning users – they never find the reset button.
Sadly – both of these arguments are pretty good. The notion of state saving across navigation kind of comes form the “portal” world where there are multiple tools on a page and interactions with one tool do not change the state of another tool. Effectively you *had* to save state when multiple portlets were active (especially on the same page). Hence state saving as default throughout the life of Sakai so far.
We had always talked about an “option” because there was such strong (and valid) disagreement. For 2.3 there will be just such an option:
portal.experimental.auto.reset=true
We will ship with the default turned off – kind of like a provisional feature. The feature works and is very clean – it only affects the portal code (Charon) – there are no changes to tools or filters or any part of the Sakai framework. This is literally “reset tool state” when navigating back to a tool. Frankly, if folks really felt strongly this is so clean it could be a personal preference – but that is another debate entirely.
I would like folks to use this and experiment with this.
This could be easily back-ported to 2.2. With some effort it could even go back to 2.0 and 2.1 (commits 14687 and 14596). All of the modifications were done this week. I am not going to do these back ports – I need to get back to marketing Sakai – Integration week has been fun but I don’t have the luxury of coding much any more.
Looking forward – I think that we need to get community reaction about how to go forward – I am sure the discussion will be lively. I see a few diffeent directions this might take (debate over the default – always fun and debate whether or not we make this a personal preference).
I also think that as we move towards JSR-168 and an even more “portlet view” of the world, we might need to revisit this again so as to properly fit into portals.
Nothing is simple – but at least for now we have options.