You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
While i was thinking about implementing #1162 (comment) for @PrefChange, i realized it it is not easy to implement with existing ValidatorParameterHelper code. Then completely refactoring the class into a fluent API came into my mind. So we can write validations like this:
I think this covers any possibilities, and with this all pamater validation can be handled by calling one method chain (for example an additional zeroOrOneParameter() call is not needed).
@yDelouis@dodgex@DayS i would like to implement this, but please let's discuss the feature, is it needed at all and what should be the exact design if it is?
It would be great.
Please, note that I changed a bit the validation in my plugin branch so that it is simpler. There is nothing complicated but it will be hard to maintain the two branches if they are divergent.
I think we should merge these big changes ASAP, because maintaining them is not easy. Currently there are 3 big PRs which change the whole codebase: #1226, #1280, #1198 and plugins.
While i was thinking about implementing #1162 (comment) for
@PrefChange, i realized it it is not easy to implement with existingValidatorParameterHelpercode. Then completely refactoring the class into a fluent API came into my mind. So we can write validations like this:I think this covers any possibilities, and with this all pamater validation can be handled by calling one method chain (for example an additional
zeroOrOneParameter()call is not needed).