hi
> that on backtracking on Netscape becomes impossible since it claims my page
> came from a post.
Actually it is possible, BUT your users have to agree to hit the button
on the panel that comes up to allow the page to refresh itself (which in
turn requires re-submitting a form). Since the buton sure looks like an
error panel odds are they will forward track or backtrack again rasing
the same panel again...
> came from a post. In IE it seems to ignore the flag and display to old page
> anyway.
Well, you must be using IE3 or earlier. IE4 and later throw up the exact
same 'error message'.
This is a matter of taste and trade-offs. I don't care if the DG isn't
in synch. Next time my users access the app the page they get back will
be in synch. Should they ever try to make a state change to the
database, EOF makes sure everything's in synch and that nothing changed
under me. I am ensured that I can synch up just-in-time.
Note that Other things besides just the DG refer to session state. What
do you want to do? Expire every page just because the AppServer state
changed? Since odds are every page will in some way display based on
Session state, do you want every page refreshed if backtracked to? Then
there is the DB... you can't be guaranteed that that will be in synch
with your app server (unless you refetch everything you previously
fetched on each request). Do you want the app server and DB and every
browser always completely in synch?
Keep in mind that should the user backtrack to a page and click on a
link, the page that is returned will be refreshed (just-in-time) which
is usually benign. Also, if the user clicks on something in the page
that should no longer be visible, WO will ONLY refresh the page; nothing
else will happen.
Most web apps with session state (not just WO ones) use different lower
tech techniques to deal with backtracking...
1) Prominently position navigation controls so the user is tempted to
use them instead of the browser buttons (A pervasive reusable component
used for navigation is good idea here)
2) Warn the user that they will get better results if they don't use
the browser backtrack buttons.
3) Links that take a user to a state-ful place (like a
ComponentAction WOApp) use JavaScript to popup a browser window (that
loads the first page of the app) without ANY navigation buttons.
One (more complicated) solution is to let users backtrack, but trap
actions from a backtracked page on the server and raise an error page.
One way to implement this solution is to place a token in a hiddenfield
(or even cookie) on the page. This token might be a label or counter. If
a user doesn't backtrack on the next operation, the server can verify
this by checking this token's value. Maybe the last transaction was #8,
if the user doesn't backtrack, the value in the session and in the
submitted page will be #8. If they do backtrack a couple times, the
hiddenfield might contain #6. The server can trap this and instead of
letting normal processing occur, return a different page instead, a
BacktrackError page, say. This page might tell the user... "Stop
backtracking damnit! " and offer a link to the last page the user was
on.
d
"Robert J. Stuart" wrote:
>
> It is my understanding that with display groups you need to turn
> setPageRefreshOnBacktrackEnabled on so that when the user backtracks the
> display group gets updated to know which group the user may be selecting
> from. I don't understand how people can use this since for me once I turn
> that on backtracking on Netscape becomes impossible since it claims my page
> came from a post. In IE it seems to ignore the flag and display to old page
> anyway. The page I backtracked to was generated with the prev/next batch as
> links not as a form submit. There are forms on the page though since I am
> using a component similar to the navigation bar in WoExtensions.
>
> How do people deal with this/ use this. Also I agree with the prior
> question it seems that I would not want to turn this on for an entire app
> but page by page.
>
> Bob Stuart
> Lockheed Martin
