The AbstractValidator approach is fine, or you can do it the shorter
way the Igor showed.

Either way, when the page that has the username is submitted, you're
going to have to write that record to the database, even if you don't
have all the info.  The way you wrote the question, I presume you are
collecting info on multiple pages.  First page gets username et al, then
next > as in a wizard page.

When you check the username and it's not in use, write the record.
The table should have audit columns that include record_status and
last_mod_datetime.  Initially write the record with status "I" (in process)
and when the user is finished registering, update it with "A" (active).

If the user fills out page 1 and then closes the browser you'll have a
record there with status "I".  You'll need a job that fires off periodically
(I do it once a day at 2 or 3am) that finds those records that are more
than, say, 24 hours old, and purges them.

Then, to quote a sith, there is no conflict.


Paul Huang wrote:
> Ryan Gravener-3 wrote:
>> I think you are overcomplicating things.  Validate the users input, if
>> two users want the same name within 1 second of each request you
>> probably have bigger problems to deal with.  
> So you think my current solution (extending "AbstractValidator") is OK?
> But I still need to catch nonunique exceptions when saving all user
> inputs. 
>> Anyhow,  when submit is
>> called, if you get a nonunique exception.  Catch in dao/service and
>> throw an exception wicket can handle and present.
>> Ryan Gravener
>> For additional commands, e-mail:
> Can you be a little bit more specific? After I catch a nonuqniue
> exception,
> how should I change the page markup to present an error message? Any 
> examples/references  will be helpful.

View this message in context:
Sent from the Wicket - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to