Feed unpadded strings to validation on write

[f4lco]

When writing, I think the validation routine should work on unpadded strings. This has two reasons:

Validation stays the same

When

• The reader part does read → trim → validate
• Then the writer part should do write → validate → pad.

Only this way the input to the validation stays the same, because it consists of the string without padding.

Avoids having the padding character as part of the format

Below tests would also pass if the padding was part of the format or option string, as in

@FixedOption(options = {"blue ", "white"})
private String color;

But this would require changing the options or the date format every time the padding requirements change (padding character, padding length) which is not desired. Adding the padding as part of the format feels like a hack and escapes the control of FixedField#padding, for example.

Thank you for taking the time 👍

[f4lco]

@joutvhu what's your opinion on this? Can we follow up on this PR? Thanks.

[joutvhu]

Writer: pad is required (You have to fill something in the string to make it long enough, or cut it off if it's too long)

Reader: trim is optional (You can use @FixedField.keepPadding to decide whether to keep padding or not)

[f4lco]

@joutvhu thank you for your reply. After a fair bit of pondering, I see my change cannot fulfil the following test case:

@Test
void optionsWithPadding() {
    Stone stone = new Stone();
    stone.color = "blue";

    assertEquals("blue ", fixedParser.export(stone));
    assertEquals("blue ", fixedParser.parse(Stone.class, "blue ").color);
}

@FixedObject
@Data
public static class Stone {
    @FixedField(length = 5, keepPadding = KeepPadding.KEEP)
    @FixedOption(options = {"blue ", "white"})
    private String color;
}

No matter which values I put into @FixedOption, either the reading or the writing validation fails. That helped me see what you meant with "pad is required / trim is optional". Thank you for your expertise & and for introducing the proper fix on the development branch!

That makes me think: KeepPadding.KEEP also seems then to be a good candidate for an additional test case, just to avoid future regressions. I updated this PR with the new test case, please have a look.