| [neon] How to best migrate away from ValidateOnAnyKey [message #1725714] |
Mon, 07 March 2016 09:13  |
 Urs Beeli
Messages: 573
Registered: October 2012
Location: Bern, Switzerland |
Senior Member |
|
|
We are making extensive use of the validateOnAnyKey feature in our application that we are migrating to Neon.
According to the migration guide, this has been removed, instead it seems we need to work with the updateDisplayTextOnModify mechanism.
However, this presents us with quite a few issues that we're uncertain about. Mainly:
- the old mechanism took care of parsing/formatting, do we need to do this ourselves?
- in the old mechanism, we could throw a veto exception to set the error state, is this still possible?
- in the old mechanism, we could modify the value (stripping out undesired values etc) by returning a modified value from execValidateValue(). How do we do this now? Just set a new display text? Will this not cause an endless loop of calls to execChangedDisplayText?
- we now need to parse the display text (which is a string) into whatever value the field has (i.e. an integer) which means we also have to add exception handling, which makes this pretty cumbersome. is there an elegant way on how to handle this?
To illustrate our problems, here are two different applications that we have so far used:
Example 1: validating an integer value
@Override
protected boolean getConfiguredValidateOnAnyKey() {
return true;
}
@Override
protected Integer execValidateValue(Integer rawValue) throws ProcessingException {
if (rawValue == null) {
rawValue = super.execValidateValue(rawValue);
} else {
checkValidEvuGruppeBasisNummer(getSystemgruppeField().getValue(), rawValue);
}
return rawValue;
}
needs to be changed to
@Override
protected boolean getConfiguredUpdateDisplayTextOnModify() {
return true;
}
@Override
protected void execChangedDisplayText() {
// TODO [neon] verify functionality
String displayText = getDisplayText();
if (displayText != null) {
try {
Integer rawValue = Integer.parseInt(displayText);
rawValue = interceptValidateValue(rawValue);
setDisplayText(rawValue.toString());
} catch(NumberFormatException ex){
// TODO: figure out what to do here
} catch(ProcessingException ex) {
// TODO: figure out what to do here
}
}
Example 2: Modifying input
@Override
protected boolean getConfiguredValidateOnAnyKey() {
return true;
}
@Override
protected String execValidateValue(String rawValue) throws ProcessingException {
if (rawValue != null) {
StringBuilder result = new StringBuilder();
for (int i = 0; i < rawValue.length(); ++i) {
Character value = rawValue.charAt(i);
if (Character.isDigit(value) || value.equals('*')) {
result.append(value);
}
}
return result.length() == 0 ? null : result.toString();
}
return null;
}
needs to be changed to this
@Override
protected boolean getConfiguredUpdateDisplayTextOnModify() {
return true;
}
@Override
protected void execChangedDisplayText() {
try {
String validatedValue = interceptValidateValue(getDisplayText());
setDisplayText(validatedValue);
} catch (ProcessingException e) {
// TODO: figure out what to do here
}
}
As you can see, the overhead of extracting the display text, in some cases converting it to another data type, handling new error cases and setting a potentially modified value back to the field requires a lot of boilerplate code (parsing and formatting is not even taken into account, or is this not needed at this stage yet?).
Is this really how this is supposed to be done or are we failing to see a more elegant way to do this?
|
|
|
|
Powered by
FUDForum. Page generated in 0.04551 seconds
] 
Search
Help
Register
Login
Home
