<div dir="ltr">Hi all,<div><br></div><div>I've pushed the consolidated proposal on the validation of container elements as an appendix to the spec draft now:</div><div><br></div><div> <a href="http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction">http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction</a></div><div><br></div><div>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 [1] to get a feeling for the indented semantics.</div><div><br></div><div>Towards the end of the appendix there's a list of open questions [2]. 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.</div><div><br></div><div>In the meantime we'll continue with implementing this proposal in the RI as far as it's defined.</div><div><br></div><div>Thanks,</div><div><br></div><div>--Gunnar</div><div><br></div><div>[1] <a href="http://beanvalidation.org/latest-draft/spec/#_examples_11">http://beanvalidation.org/latest-draft/spec/#_examples_11</a></div><div>[2] <a href="http://beanvalidation.org/latest-draft/spec/#_open_questions">http://beanvalidation.org/latest-draft/spec/#_open_questions</a></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-22 17:15 GMT+01:00 Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
It has been silent on the surface, but that doesn't mean we haven't been busy :)<br>
<br>
I've spent some time working on a proof of concept implementation of<br>
the value extraction proposal (BVAL-508) which has been added to the<br>
RI earlier this week [1]. This effort brought a fair bit of insights<br>
and clarity which is reflected in an updated proposal that you can<br>
find at [2].<br>
<br>
So if you can spend some time and review it, that'd be much<br>
appreciated. It's a bit more formalized than the original proposal and<br>
also takes an opinion on some of the original questions. I tried to<br>
cut down a bit on the many loose ends to advance the matter a bit, but<br>
if you are doubtful about any of the directions taken, please speak<br>
up.<br>
<br>
Also the ValueExtractor contract has evolved a bit. It now allows for<br>
a nicely uniform, yet efficient implementation of the single value and<br>
multi value case. Refer to the pull request for the details. There are<br>
some open questions at the end of the document. Feedback on these (and<br>
of course any other parts of the document) are highly welcome. I've<br>
checked on the previous threads and discussions of the matter (e.g.<br>
Hendrik's extensive feedback) and hope the proposal covers all the<br>
essential items. Please let me know if anything is missing.<br>
<br>
The idea is that we add this version of the proposal as an appendix to<br>
the spec, adjust the RI to conform with it (it already does more or<br>
less) so we can aim for a first alpha release of spec and RI very<br>
early next year. That will allow people to get their hands on this<br>
feature and play around with it a bit, hopefully resulting in some<br>
more feedback from the outside, too.<br>
<br>
My main remaining questions are:<br>
<br>
* Is allowing to put constraints to an element but automatically<br>
applying them to the wrapped value the right thing to do? I can see<br>
the concerns about lacking comprehensibility (it's working based on<br>
the presence of an automatically unwrapping value extractor), but then<br>
it's needed to support "@Email StringProperty email"<br>
* Should we support nested collections (e.g. List<Map<String, @NotNull<br>
String>> addressesByType). It hasn't been supported before, but I can<br>
see how it's more appealing with type parameter constraints. But it<br>
adds complexity, too.<br>
<br>
Looking forward to your feedback,<br>
<br>
--Gunnar<br>
<br>
[1] <a href="https://github.com/hibernate/hibernate-validator/pull/592" rel="noreferrer" target="_blank">https://github.com/hibernate/<wbr>hibernate-validator/pull/592</a><br>
[2] <a href="https://github.com/beanvalidation/beanvalidation-spec/pull/116" rel="noreferrer" target="_blank">https://github.com/<wbr>beanvalidation/beanvalidation-<wbr>spec/pull/116</a><br>
</blockquote></div><br></div>