Chain custom validation about openapi4j HOT 4 CLOSED

Hi,

There is no way to access core validators.
I suggest to declare a new keyword (x-date for example) in your Document Description for your specific needs then format keyword can be processed normally.

from openapi4j.

Unfortunately I have no control over the spec files. Although I could iterate the parsed schema and modify it in memory to add the extensions.

I think supporting custom formats without spec modification is desirable. The spec supports custom formats - so validating the added custom formats in addition to the standard ones will be a common use case. Validating keywords other than 'format' will also likely want to fall back to the 'stock' validator after performing the overloaded operation. (e.g I will want to trap all 'type' keywords, but I would prefer to not re-implement the typevalidator).

Can the 'validate' function of the custom validator simply return a boolean which indicates whether openapi4j should proceed onto the core validator after processing?

I can imagine you may want a 'preValidate' and 'postValidate' hook as well(?). The validation hooks are what differentiate openapi4j from other validators so it would be good to make them powerful. But at the least - a boolean which controls the chaining to the core validator would be sufficient.

from openapi4j.

I implemented a chaining behaviour for validators.
Now validate method returns a boolean to break or continue the chain.
You can have a look at the updated README.md for further info.

Are you able to validate this in latest 0.8-SNAPSHOT?
Thanks

from openapi4j.

Thanks for the changes. I gave them a quick test and it appears to be working.

Another approach could be to pass the next validator in the chain to the validation function as a parameter. The custom validation function can then choose to call the next one or not. It would allow it to post process the validation results, e.g strip out certain errors from core validators. It does put the onus on the custom function to chain correctly however.

But the boolean return approach is likely to be adequate 90% of the time.

from openapi4j.