What happens when you call setResponsePage() inside a Wicket event handler?

setResponsePage() tells Wicket which page to render for the current response, effectively performing a server-side redirect (or, depending on configuration, a render-in-place) from within an event handler like onClick() or onSubmit(), rather than the handler needing to return anything or manipulate the HTTP response directly.

Calling setResponsePage(TargetPage.class) passes a page class, letting Wicket construct a fresh instance (useful for bookmarkable navigation); calling setResponsePage(new TargetPage(someModel)) passes an already-constructed instance, preserving whatever state that specific object was built with. Once called, any code after it in the same handler still executes (it doesn't immediately halt like a thrown exception would), so it's a convention to make it the last meaningful statement in the method.

Under the hood, Wicket typically issues an HTTP redirect to the new page's URL (the "redirect-after-post" pattern), which is what prevents a browser refresh on the resulting page from re-submitting the original form.