Hi All,
Having had time to take a step back from the back button issues, here are my thoughts on exactly what we are trying to achieve plus some other interesting observations......
Requirement
Issue:
User presses the back button on their browser
Expected Result:
The user is displayed an 'appropriate' page. By 'appropriate' page we mean one of the following:
1. The exact page that the user saw previously
2. The same page that they saw previously but updated to reflect underlying model and/or contained component changes
3. A stale data error page with appropriate link to either the application home page or another 'bookmarkable' page within the application.
4. The application home page or another 'bookmarkable' page within the application but with a feedback panel informing them that the data they were working with is no longer valid and asking them to reselect from the up-to-date set of data
Obviously, if the page is not stale then it can just be re-rendered. Issues only occur if the page is stale for some reason.
Options 3 and 4 are not difficult and are in fact just variations of the same thing. The configuration choices are whether to go to an error page and then on to another page or whether to go direct to that page and display a feedback panel.
Regarding options 1 and 2, there are actually TWO totally different issues (and I think this is where much of the confusion has been going on because we have been mixing them up):
a) The reason the page is stale is because the model data has changed since it was rendered
b) The reason the page is stale is because the components on the page have changed since it was rendered
A page can be stale for reason 'a' OR reason 'b' OR both reasons 'a' and 'b'.
I think from a solution point of view we need to consider how to handle 'a' and 'b' separately. The main reason for this is that 'b' is something that is entirely within the Wicket core and how we deal with containers, components and replacement; whereas 'a' has an impact on people who develop applications using Wicket. We can therefore do some clever stuff in solving 'b' without having too much impact on the public API of Wicket. For option 'a' we need to come up with something that works transparently for most cases makes it easy for users to introduce their own level of control.
There are also additional issues associated with reason 'a' that a developer using Wicket has to consider. Things like: what if the data for the model we want to redisplay is no longer available and we didn't/couldn't keep it in memory or recreate it; what happens if we display a page to the user then they try to commit an update but the underlying data has gone or has been changed in another transaction; and so on. These sorts of issues are probably not something easily addressed by Wicket as they will be very application specific. Wicket can only help people out in making it easier to implement their chosen decision. Some applications may only want to support the back button if the data used as the page model is still present in the database, others if it has not been changed by someone else and so on.
This kind of conceptual separation between is also something we need to think about for clustering purposes as well as there appears to be completely different clustering criteria between Wicket pages and component and the models.
Regards,
Chris
