I'd just keep a workflow identifier in the database If your workflow is so important, sooner or later your business people will want to an know about aborted wizards anyway.
My 2 cents Sven Dan Retzlaff <dretzl...@gmail.com> schrieb: >Hi all, > >We have a wizard workflow for our users that collects various inputs, and >when submitted, persists entities and kicks off some processing. After the >wizard is submitted, the user should not be able to navigate back and >resubmit the wizard. The obvious solution of maintaining a boolean >"isSubmitted" state within the page does not work, because during wizard >navigation many page IDs were created due to model and hierarchy changes. >The isSubmitted=true is seen by the first history entry, but page instances >further back have isSubmitted=false. Another solution is >setVersioned(false), but we like the back button to work while wizard is >active. > >It seems like we need to maintain wizard state at a higher scope such as >the session, keyed uniquely by some wizard instance identifier (maybe a >UUID). Ensuring that this set of submitted (or in-progress) wizards remains >bounded seems challenging, though probably not a practical concern. Do you >have a more clever solution to this problem? > >Regards, >Dan
