Handle browser back

Topics: Web Client Software Factory
Oct 31, 2006 at 3:45 PM
I have a question about the handling of browser back button in the reference implementation.

Login into the ETF application as admin. Created transfers and clicked on Next. The ConfirmPage showed up. Instead of clicking on the "Change" or "Submit" button, I clicked on the browser back button to get back to the NewTransfer page. From this point on, the "Next" button wouldn't move to next page anymore.

What could be the cause of this? Is it because the current state for this session is still the ConfirmPage? Is there a solution for this in the plan?

The "browser back" scenario is quite common in a web application. I would love to see it working in this design.

Thanks.

Jane

Oct 31, 2006 at 11:17 PM
Hi Jane,

You're right - the current drop of the factory does not include support for back button operations. But we recognize this as an important page flow requirement and our next drop should include some new enhancements that take this into account. We look forward to hearing what you think.

Thanks,
Tim
Nov 1, 2006 at 7:16 AM
We had awful trouble with the back button in our implementation mostly because you have no idea if when a request is the result of the back button being pressed.

By the time it hits the server it looks like any other request and has to be treated like any other direct navigation.

I'd be very interested in hearing how you handle this requirement and of course am happy to share any of our experiences to help come up with a solution.

Stephen ...
Nov 1, 2006 at 5:36 PM
Absolutely! Browser back button support is critical. We are planning to work on it this week, and hope to include it in the next drop of the RI.

You are correct about the issue. The underlying workflow does not receive any notification of the state change. Therefore, it still believes the that the current state is the Confirm page, causing the Next button to misbehave.

Our planned solution involves using an HTTP handler to intercept posts and either a) change the current state of the underlying workflow based on which view is making the request, or b) redirect the view to the current state identified by the underlying workflow (in the case of a "constrained" workflow). Again, we hope to complete that work this week.

Alan
Nov 2, 2006 at 8:01 AM
Your solution is exactly what we opted for with some gateway checking before the requested page is loaded resulting in either a successful page load and subsequent state change or a redirect back to your current state.

I our experience, users will request a "constrained" workflow but with the back button use being valid. That's when it starts to get complicated as you either have to configure a "back" as a valid transition from every step or you build in some mechanism to track your history (server side).

Stephen ...