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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
