+BV API+
* Move SPI to BV (also rename {{UnwrapValidatedValue}} to the name suggested in [~emmanuel]'s proposal
* Support nested extraction, e.g. {{Optional<List<@Valid Order>> orders}}; should we do it?
* Type parameter constraints via XML
* Add property for defining extractor(s) in XML
* Decide on whether to keep supporting {{@Valid Optional<Foo>}} or not
* Exposure of type constraints and type-parameter level cascades in the meta-data API
* Allow for custom extractors per bootstrapped validator (context)
+Implementation+
* Implicit unwrapping, e.g. {{@Min(1) IntegerProperty myInt}}; currently an explicit {{@UnwrapValidatedValue}} is required
* Move retrieval of extractors for constraints (not cascaded validation) to metadata retrieval time and cache them
* Correct implementation of most specific extractor in {{ValueExtractors}}
* Revisit formats for node keys (from [~emmanuel]: I would have preferred something like "addressByType[key('too short')].value", At least for strings and any type that we don't know and will be toStringed. We make exceptions for numbers, booleans, dates
* Require {{@ExtractedValue}} in extractor implementation when dealing with the annotated object itself (currently that's implicitly assumed when {{@ExtractedValue}} is not there)
* Type parameter constraints programmatic API
* Review usage of {{TypeHelper#getErasedType()}}; should the non-erased type be used somewhere?
* Raise error if no extractor is found during cascaded validation
* Revisit usage of {{TypeParameter<?>}}; I think we only ever deal with {{TypeParameter<Class<?>>}}. Should we use that instead?
* Remove value unwrappers from reference docs (/)
* Update documentation: see for instance paragraph "With custom parameterized types" in ch02.asciidoc
* Which cascadable to chose for {{validateValue()}} and cascaded validation? This has never been supported by the spec, but the RI is doing it; now the question is what to do for maps with key and value extractor for instance?
* Revisit formats for node keys (from [~emmanuel]: I would have preferred something like "addressByType[key('too short')].value", At least for strings and any type that we don't know and will be toStringed. We make exceptions for numbers, booleans, dates
* Require {{@ExtractedValue}} in extractor implementation when dealing with the annotated object itself (currently that's implicitly assumed when {{@ExtractedValue}} is not there)
* Explore versability of the extractor SPI; e.g. try and see whether it fits for Ceylon collections
* Implement {{@ConstraintApplyTo}}
|
|
