[bv-dev] Updated proposal for container value extraction
gunnar at hibernate.org
Fri Jan 6 10:43:02 EST 2017
I've pushed the consolidated proposal on the validation of container
elements as an appendix to the spec draft now:
Can you please give it a read and raise your opinion on it. I know that
Hendrik and Christian had some remarks/concerns originally, I'd hope the
new one can address them appropriately. Apart from the more formal
specification I recommend you take a look at the examples  to get a
feeling for the indented semantics.
Towards the end of the appendix there's a list of open questions . Any
input on those is highly welcome. E.g. 1, 2 and 5 would deserve some more
opinions. Also what's your take on the ValueExtractor API in general? I'll
wait a few more days to let you form some thoughts and then start a
specific thread per open question.
In the meantime we'll continue with implementing this proposal in the RI as
far as it's defined.
2016-12-22 17:15 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
> It has been silent on the surface, but that doesn't mean we haven't been
> busy :)
> I've spent some time working on a proof of concept implementation of
> the value extraction proposal (BVAL-508) which has been added to the
> RI earlier this week . This effort brought a fair bit of insights
> and clarity which is reflected in an updated proposal that you can
> find at .
> So if you can spend some time and review it, that'd be much
> appreciated. It's a bit more formalized than the original proposal and
> also takes an opinion on some of the original questions. I tried to
> cut down a bit on the many loose ends to advance the matter a bit, but
> if you are doubtful about any of the directions taken, please speak
> Also the ValueExtractor contract has evolved a bit. It now allows for
> a nicely uniform, yet efficient implementation of the single value and
> multi value case. Refer to the pull request for the details. There are
> some open questions at the end of the document. Feedback on these (and
> of course any other parts of the document) are highly welcome. I've
> checked on the previous threads and discussions of the matter (e.g.
> Hendrik's extensive feedback) and hope the proposal covers all the
> essential items. Please let me know if anything is missing.
> The idea is that we add this version of the proposal as an appendix to
> the spec, adjust the RI to conform with it (it already does more or
> less) so we can aim for a first alpha release of spec and RI very
> early next year. That will allow people to get their hands on this
> feature and play around with it a bit, hopefully resulting in some
> more feedback from the outside, too.
> My main remaining questions are:
> * Is allowing to put constraints to an element but automatically
> applying them to the wrapped value the right thing to do? I can see
> the concerns about lacking comprehensibility (it's working based on
> the presence of an automatically unwrapping value extractor), but then
> it's needed to support "@Email StringProperty email"
> * Should we support nested collections (e.g. List<Map<String, @NotNull
> String>> addressesByType). It hasn't been supported before, but I can
> see how it's more appealing with type parameter constraints. But it
> adds complexity, too.
> Looking forward to your feedback,
>  https://github.com/hibernate/hibernate-validator/pull/592
>  https://github.com/beanvalidation/beanvalidation-spec/pull/116
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the beanvalidation-dev