Add @Length as built-in validator #91
Conversation
Now this is pretty much duplicate functionality of @SiZe so there is some argument for not adding this. Argument for adding @Length is that: - @Length is what existing users of jakarta validator are expecting to be able to use - The error message "*Length* must be ..." is better for end users to understand wrt string lengths - The string length is probably the MOST COMMON validation requirement and as such its important that it is done well. Although this can be done with say @SiZe(max=...) the error message has 'Size' vs 'Length' and maybe not ideal in that sense.
Sonatype Lift is retiringSonatype Lift will be retiring on Sep 12, 2023, with its analysis stopping on Aug 12, 2023. We understand that this news may come as a disappointment, and Sonatype is committed to helping you transition off it seamlessly. If you’d like to retain your data, please export your issues from the web console. |
| @@ -112,6 +113,37 @@ public boolean validate(Object value, ValidationRequest req, String propertyName | |||
| } | |||
| } | |||
|
|
|||
| private static final class LengthAdapter implements ValidationAdapter<Object> { | |||
There was a problem hiding this comment.
wait why do we need a separate adapter? can we not reuse the size adapter? since the logic is the exact same?
There was a problem hiding this comment.
since the logic is the exact same?
To be exactly the same, @Length would apply to Collection, Map and Array. Currently in this PR @Length only applies to CharSequence. Hmm, thinking that probably doesn't matter or could be seen as a positive.
There was a problem hiding this comment.
Merging in by just re-using the SizeAdapter for now.
Now this is pretty much duplicate functionality of
@Sizeso there is some argument for not adding this.Argument for adding @Length is that:
@Lengthis what existing users of jakarta validator are expecting to be able to use@Size(max=...)the error message has 'Size' vs 'Length' and maybe not ideal in that sense.