Comments (8)
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.
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.
Related Issues (20)
- int64 or int32 format not identified by openapi4j tool HOT 3
- Mandatory element missing is not throwing error HOT 3
- Some of the optional fields when using oneOf are not being validated HOT 1
- Convenience methods to support easy response validation HOT 3
- Spring Adapter
- Validating data against schema with $ref HOT 2
- Incorrect path pattern for path parameter HOT 2
- Creating schema references programatically HOT 7
- OpenApi3Parser - add ability to provide spec string/stream to parse method HOT 2
- Integer formats not identified in 1.0.5 version openapi4j tool HOT 1
- Scheme that contains path parameters with minus sign in name fails validation HOT 1
- Throw ValidationException on path pattern collision
- Give the option to throw a validation error with no response validator is found
- RequestValidator fails when path params contains minus char HOT 1
- Get the path of an operation HOT 2
- ADDITIONAL_PROPS_RESTRICT = true rejects all attributes HOT 1
- Duplicate properties, Duplicate Headers are not being validated HOT 2
- Remove toString() call to replace NPE with more meaningful message
- Validation of callback URLs can't handle allOf/oneOf/... HOT 3
- Path pattern collision leads to incorrect Path selection
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openapi4j.