Hi Sven, The form validator is not added to the form. It just helps to display the error after #onSubmit() which I am sure is called otherwise the service method would not get called. It is the return of the service method that creates the error response. That is why I am keen on learning about an applicable Wicket pattern which is different from validation before #onSubmit().
Regards, Bernard On Mon, Jun 8, 2015 at 8:02 PM, Sven Meier <[email protected]> wrote: > Hi, > > After Form#onSubmit(), without any error on the Wicket side, the service >> tier has a validation error that belongs to a known FormComponent. With a >> class extending AbstractFormValidator, the known FormComponent gets the >> error which is shown in context correctly >> > > if a FormValidator reports an error during validation, #onSubmit() will > not be called and the input will stay in the field. > > Are you adding the FormValidator to the form, or are you triggering its > validation by yourself? > > Regards > Sven > > > > On 08.06.2015 09:12, Bernard wrote: > >> Hi, >> >> I hope someone can help me learn and understand this. >> >> After Form#onSubmit(), without any error on the Wicket side, the service >> tier has a validation error that belongs to a known FormComponent. With a >> class extending AbstractFormValidator, the known FormComponent gets the >> error which is shown in context correctly. Great. >> >> However, after re-display of the page with the error, the original input >> is >> lost from the field because the service method does not return it and it >> is >> not in the model. I guess this is by design and it makes sense to me. So >> in >> order to fix this, the service would need to return the erroneous value in >> the erroneous field. >> >> My question is what the correct Wicket pattern would be for this type of >> use case. Can I get the erroneous user input back from Wicket at this >> stage >> (after onSubmit() ) and push it back into the FormComponent? >> >> The use case by the way is a model object that has two ID fields one >> transient and one persisted while there is only one FormComponent for it >> that has a custom IModel with getters and setters that are connected to >> the >> two ID fields alternatively. This solves the problem where an ID is either >> user generated or system generated depending on some entity type. BTW I >> feel that Wicket lets me handle this very well. >> >> Many thanks. >> >> Bernard >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
