Preventing users from re-submitting wizards

[Dan Retzlaff <dr...@gmail.com>]

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

Re: Preventing users from re-submitting wizards

[Martijn Dashorst <ma...@gmail.com>]

Sounds like a problem waiting for CDI.

https://www.42lines.net/2011/11/15/integrating-cdi-into-wicket/

Martijn

On Wed, Jul 18, 2012 at 1:42 AM, Dan Retzlaff <dr...@gmail.com> wrote:
> 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



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org