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
