[bv-dev] Updated proposal for container value extraction

[Gunnar Morling]

Hi all,

I've pushed the consolidated proposal on the validation of container
elements as an appendix to the spec draft now:

    http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction

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.

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.

In the meantime we'll continue with implementing this proposal in the RI as
far as it's defined.

Thanks,

--Gunnar

[1] http://beanvalidation.org/latest-draft/spec/#_examples_11
[2] http://beanvalidation.org/latest-draft/spec/#_open_questions





2016-12-22 17:15 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi,
>
> 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 [1]. This effort brought a fair bit of insights
> and clarity which is reflected in an updated proposal that you can
> find at [2].
>
> 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
> up.
>
> 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,
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-validator/pull/592
> [2] https://github.com/beanvalidation/beanvalidation-spec/pull/116
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170106/74eafb2d/attachment-0001.html