Per call context object available to custom validators. about openapi4j HOT 8 CLOSED

Sounds fair to me.
As a quick guess, I think the wrapper class (not convinced by ValidatingContext naming tho) is the only (clean) way to achieve this.

Maybe this should wait the closing of #80 to avoid many conflicts and get a readable PR?
I still need to add more tests and raise the code coverage.

from openapi4j.

I wrapped the ValidationResults with a delegate class, ValidationDetail. This required a lot of renaming, perhaps not that clean.

Take a look at this diff if you can:
master...smhc:validating_context

Alternative solution would be to simply support 'customData' on ValidationResults directly. But I think having it separate makes sense. It may be worth moving the 'crumbs' stuff into ValidationDetail as well - and keep the results only containing the results (List<ValidationItem> items).

Either that or just rename 'ValidationResults' into something more meaningful (a shame ValidationContext is already taken) and have it maintain all the 'customData', 'crumbs' and 'items'.

from openapi4j.

Thinking further about ValidationDetail wrapper I've come to believe this will be an open door to low cohesion path.

So, new proposal, what about a new DataContext<T> object with a single T get() method as an input?

pros:

• fully generic (avoiding casting too)
• ability to add any methods in T complex object.
• enclosing delegate pattern (what for? I don't know but possible).
• no additional code to support on my side (mostly method signatures).
• no messy ValidationResults handling.
• cohesion.

cons:

• parameterize all schema validators with T is a requirement.
• adding 2 methods operation validator module, 1 to modify on SchemaValidator. (not really a cons...)

from openapi4j.

Is this change what you were thinking? I haven't tested it, but I suppose it could work ok.

master...smhc:data_context

It was my initial thought to add an extra param, but it seemed invasive. In the end it's probably cleaner.

from openapi4j.

I unthinkingly closed this issue, sorry for that (when merging of #84, that was not supposed to be published).

Are you able to tell if it suits your needs?

I reverted back to wrapper conception with, hopefully, a more meaningful naming.

from openapi4j.

I tested out the changes and they accomplish what I want, thanks for your help.

I may also need the ability to identify the exact node in the source at validation time. The crumbs get me 90% there, but arrays are problematic as we don't have the item number, and each item could be a different "shape". I will think about this some more, logging 'INFO' records and post processing may be adequate for these cases.

Do you have a date for releasing these changes (0.9) to maven central?

from openapi4j.

I'm aware of indexes.

The only thing that could be done is to append the index before 'items' crumb but also after the property if any adding a crumb instead of merging it.

This would result to something like:

foo.[1].bar...
foo.[1].<items>.bar...

[0].baz...
[0].<items>.baz...

Not sure if it's helpful.

from openapi4j.

I think something like this might be required. It's the only way to be sure to have the correct crumb for a model that is very dynamic per item. However it would quickly add up if there were thousands of entries in an array.

Perhaps the default should be to aggregate crumbs without indexes, and custom validators could have a way to flag adding items with their associated indexes. Or just a flag set in 'ValidationContext'.

In any case it's not relevant to this issue. I am happy to close this one and raise a new issue for the index problem.

from openapi4j.