I’ve been developing my first application and during testing noticed
that pressing the ‘back’ button didn’t trigger initialisation code
contained with the action code.
This mattered to me because I cache information in the session and clear
it out at the end of a transaction or on a cancel. Pressing ‘back’,
though seemingly a cancel, causes the app to display erroneous
information because the cancel processing has not happened.
To get around this I have added the following to my application.rhtml
file
This prevents any pages from being cached (scriptaculous javascript
pages work just fine as you’d expect) I was just wondering whether this
was in fact a generic requirement and whether I should file a bug
report?
Has ‘back’ caused anyone else grief or is it just me? Is there a railish
way of coping with such user actions?
I like the back button, so long as Web developers aren’t trying to
thwart it. If I hit a wrong link (usually due to poor page design) I
want to go right back where I was. Not make another page fetch, not
ponder cryptic error messages, not have to figure out an escape route
via the Menu From Hell, just Go Back.
I like the back button, so long as Web developers aren’t trying to
thwart it. If I hit a wrong link (usually due to poor page design) I
want to go right back where I was. Not make another page fetch, not
ponder cryptic error messages, not have to figure out an escape route
via the Menu From Hell, just Go Back.
Quite so, but as I originally noted, it’s semantically a ‘cancel’
action, but in stateful applications where cancel may do some cleaning
up it causes problems. Thus, is the easiest thing to do just simply not
to cache pages?
though seemingly a cancel, causes the app to display erroneous
information because the cancel processing has not happened.
To get around this I have added the following to my application.rhtml
file
This prevents any pages from being cached (scriptaculous javascript
pages work just fine as you’d expect)
It doesn’t prevent pages from being cached. It’s a pragma. Nothing else.
Don’t rely on browsers implementing this the way you think it should be
implemented. The only way to be “almost” sure stuff isn’t cached is
serving https.
I was just wondering whether this was in fact a generic requirement and whether I should file a bug report?
Nope.
Has ‘back’ caused anyone else grief or is it just me? Is there a railish
way of coping with such user actions?
When it comes to caching, dynamic page contents and bookmarkable urls
you will curse the browser as there is not simple way to sync your
desired application navigation with the controls of the browser.
ajax, even though I love it, makes it even worse.
after all, it’s doable, but a huge pain in the ass…
p.s.: I also love the back button from the point of view as a user
just to realize for some folks:
i needed this huge ***load of java code just to suppress caching
of our dynamic pages and make “back” work…
// disableCaching
SimpleDateFormat f = new SimpleDateFormat(“EEE, dd MMM yyyy
hh:mm:ss”);
f.setTimeZone(TimeZone.getTimeZone(“GMT”));
String lastModified = f.format(new java.util.Date()) + " GMT";
// set modify date to current timestamp
response.setHeader(“Last-Modified”, lastModified);
// set expiry to back in the past (makes us a bad candidate for
caching)
response.setDateHeader(“Expires”, 0);
