|
[
Permlink
| « Hide
]
Rahul Akolkar added a comment - 21/Nov/05 01:56 AM
Resolving to LATER, based on feedback on the dev list from the Shale dev team.
I had resolved this to LATER based on discussions such as these:
http://marc.theaimsgroup.com/?t=113114168400008&r=1&w=2 http://marc.theaimsgroup.com/?t=113231581300002&r=1&w=2 I had a home-brew solution earlier based on Commons SCXML (see comment #1). At some point I'd like to revisit this in context of sub 1.2 JSF impls and find an acceptable solution. It is a mere coincidence that I'm reopening as Shale plans to cut 1.0.1, but its probably best at this time that I don't leave this bug ticket based on my (interpretation of the) resolution. OK, the current behavior with respect to the back button is decidedly not optimal. I've been using shale-test-dialog-basic for my experiments (I imagine the SCXML implementation will behave similarly), and have found the following:
* The server doesn't directly know that the user pressed the back button and resubmitted. * The resubmit goes back to the correct page (i.e. if you are on Page2, press Next, press Back Arrow, and press Next again, the submit gets (correctly) processed by Page2 and not by Page3). * However, the state manager would have thought you were in state Page3 above, and would (for this dialog definition) cause an error because it would be looking for a nonexistent "next" transition out of state "Page3". * In this particular sort of wizard dialog, a resubmit doesn't damage anything because it is just collecting data. You can use the token component in shale-core to catch the resubmit if that is not the case ... but then the user is stuck unless the dialog designer has provided a Cancel or Finish type control with immediate=true. I think this part of the design is acceptable. We need to think about whether we should try to include the current state identifier in the information that is saved and restored with the JSF component tree, so that repositioning might be done on the way back in, and think about what might still get screwed up. For example, with the Basic implementation there are still likely to be problems if you Back Arrow your way through a subdialog creation situation, where the depth of the stack might also need to be changed. I have a solution for this on disk (using the 'opaqueState' addition) that works with Commons SCXML v0.6, so I'm going to set a JIRA depends-on relationship for this issue with
I've committed a set of strategies for dealing with back buttons for the shale-dialog-basic implementation, as of nightly build 20061221. As soon as Rahul commits his corresponding changes for shale-dialog-scxml, we can declare this issue as "fixed".
Good catch by Rahul ... I had not yet implemented the event behavior we agreed upon when setOpaqueData() causes a change in the currently executing state. This has now been fixed for the basic implementation in a manner that is consistent with the SCXML implementation.
In addition, I've changed the default strategy for saving/restoring extended state information from "none" to "top". This is the most consistent choice with what the SCXML implementation does, and also covers the majority of use cases for recovering from back/forward button issues, without the overhead of the "stack" strategy (which can be selected if necessary). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
[shale] Maintaining dialog synchronization when browser navigation buttons are used
