+BV API+
* Support nested extraction, e.g. {{Optional<List<@Valid Order>> orders}}; should we do it? - now supported in HV
* 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)
* ValueExtractors should be CDI-enabled
* Explore whether JavaFX support should be specified per availability in platform (it may not be part of every OpenJDK or something like that)
+Implementation+
* Correct implementation of most specific extractor in {{ValueExtractorManager}}
* 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
* Type parameter constraints programmatic API
* Review usage of {{TypeHelper#getErasedType()}}; should the non-erased type be used somewhere?
* Revisit usage of {{TypeParameter<?>}}; I think we only ever deal with {{TypeParameter<Class<?>>}}. Should we use that instead?
* Update documentation: see for instance paragraph "With custom parameterized types" in ch02.asciidoc
* Which cascadable to choose 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?
* Explore versability of the extractor SPI; e.g. try and see whether it fits for Ceylon collections
* Value extractors for cascaded validation can at least be narrowed down to those extractors compatible with the declared type of the cascaded element already at initialization time |
|
