We designed our domain to use wicket's ivalidator for validation, so we get to reuse our validation in the frontend components.
-Igor On 2/17/09, walnutmon <[email protected]> wrote: > > My solution was a combination of the ideas here, let me know what you think > :) While I don't particularly love the idea of using domain exceptions to > render feedback on the front end, I don't have any control over certain > decisions; still, being able to use a strict domain and have it interact > with the UI is still a very interesting, and potentially useful example... > All of the logic in reporting an error is done within the custom component. > > public class DomainTextField extends TextField > { > > public DomainTextField(String id) > { > super(id); > add(new AbstractValidator() > { > protected void onValidate(IValidatable arg0) > { > checkAgainstModelObject(arg0); > } > }); > } > > private void checkAgainstModelObject(IValidatable validatableInput) > { > //I don't want to lose the initial value > Object tmp = getDefaultModelObject(); > try > { > setDefaultModelObject(getConvertedInput()); > } catch (final Exception ex) > {//This is the worst part IMHO, I should be checking a specific > exception > validatableInput.error(new IValidationError() > { > public String getErrorMessage( > IErrorMessageSource messageSource) > { > return ex.getCause().getMessage(); > } > }); > } finally > {//if possible, set back to the inital value > if (tmp != null) > { > setDefaultModelObject(tmp); > } > } > } > } > > -- > View this message in context: > http://www.nabble.com/Validation-From-A-Custom-Component-tp22060300p22070136.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
