Adding custom ValidatorTypeCodes

[andreasevers]

Hi,

We're very happy users of your library and would like to thank you for the brilliant work you've done.

One thing we'd like to do is to add our own custom enum values in the ValidatorTypeCode enum, so that we can override the existing error messages.
I've noticed BaseJsonValidator's parseErrorCode method allows us to specify a custom error code instead of the default one in the Json definition, but it's unclear where we could then add these custom error codes themselves.

Thanks in advance!

[stevehu]

To customize the validator is a little bit harder as we don't want to introduce dependency injection. We want to make this library a green library so that our users can use it without worrying about dependency conflicts. To customize the error message is a little bit easier. Take a look at the following class and see if it meets your requirement.

https://github.com/networknt/json-schema-validator/blob/master/src/main/java/com/networknt/schema/ValidatorTypeCode.java#L44

[andreasevers]

Did you mean the ItemsValidator or the ValidatorTypeCode itself?

Maybe I didn't understand what you meant.
What I'm interested in doing is to change the default messages in the enum constants, e.g:
In the max-length enum constant

MAX_LENGTH("maxLength", "1013", new MessageFormat("{0}: may only be {1} characters long"), MaxLengthValidator.class, 15),`

I'd like to change the messageFormat new MessageFormat("{0}: may only be {1} characters long").

How would that be done exactly?

[adityaLath18]

I think you have to download the Source project and then change the Format in the Enum class, recompile it and then use it.

[stevehu]

@andreasevers Sorry I missed your message. @adityaLath18 has the right answer at least for now. In a long term, we can externalize the error messages to a properties file as a resource; however, you still need to update, compile, package yourself.

[adityaLath18]

Hi @andreasevers, Thanks for this library.

One question, Can we add one more field in the ValidationMessage class i.e. fieldName. If we will get a proper fieldName then we can customize the message at our end by having a mapping of errorCode and custom Message at our end.
I tried to use the path field but I am getting $ for the root field and in that case, I have to split the message and then extract the field. Although it is ok , but a dedicated field for fieldName will be good I think. Thoughts?

[andreasevers]

Just FYI @adityaLath18 I'm not the author of this library, kudos go to @stevehu

[adityaLath18]

Yes sorry, I was about to mention @stevehu but accidentally I did a mistake which I realized just by your comment. Thanks for informing

[stevehu]

@adityaLath18 I think we can add a fieldName to the ValidationMessage. As you said, the path might not be enough to indicate which exact field triggers the error. Would you be able to try it out and submit a PR for this?

This is a project build by the community and I just take part of the responsibility to manage it.

[adityaLath18]

@stevehu Surely, I will try. Although I have not done this before please bear me for the first time. The open-source contribution journey starts.

[YiuTerran]

We need custom msg tips for i18n.

This lib should consider opening a register for code and msg templates.

[stevehu]

@YiuTerran I agree with you. This library is a tiny component of light-4j and i18n support wasn't in the consideration before as most users will translate the error message to something meaningful within their APIs or SPA or Mobile. At this moment, more and more users are using this library standalone or integrate with their APP and it is a good opportunity to enhance the library to add the message registration with some flexibility for customization. I would be happy to accept any PR with a proper implementation. Thanks.

[adilath18]

@stevehu Please check my pull request, I tried to add a way to add custom message.

#438