Am 01.09.2016 um 13:50 schrieb Emmanuel Bernard
<emmanuel(a)hibernate.org>:
In the past, what we have done is separate the proposal page on the
website as followed
## problem description
## Proposal 1: The salmon bagel
## Proposal 2: On the merits of veggie bagels
...
So if you have an alternative proposal, send a PR with a new section.
Also cross post it here as some people only check the ML.
On Thu 2016-09-01 13:06, Hendrik Ebbers wrote:
> How should we handle the proposals?
>
> - discuss by mail?
> - PR to:
https://github.com/beanvalidation/beanvalidation.org/blob/staging/proposa...
> - comment on page:
http://beanvalidation.org/proposals/BVAL-214/
>
> Currently I have no idea what is the right way :)
>
> Cheers,
>
> Hendrik
>
>
>> Am 01.09.2016 um 13:02 schrieb Hendrik Ebbers <hendrik.ebbers(a)me.com>:
>>
>> Hi,
>>
>> I had a deeper look at BVAL-214 (
http://beanvalidation.org/proposals/BVAL-214/
<
http://beanvalidation.org/proposals/BVAL-214/>
<
http://beanvalidation.org/proposals/BVAL-214/
<
http://beanvalidation.org/proposals/BVAL-214/>>) and have some additional input.
Since we depend on java 8 I think it would make sense to use suppliers to create the bean
mocks for validation. This can look like this:
>>
>> BeanValidator<ContactDataModel> contactValidator =
BeanValidator.build(ContactDataModel.class);
>> contactValidator.withProperty("city", () -> cityField.getText()).
>> withProperty("zipCode", () -> zipCodeField.getText());
>>
>> In addition I think that it will be important to have a better feedback for the
violations that are based on a UI field. If you have a violation based in the text of the
cityField you normally want to mark that field in the UI. I think a consumer can really
help here:
>>
>> contactValidator.withProperty("city", () -> cityField.getText(), v
-> markCityField(v));
>> By doing so you will always get the set of violations that is based on the value
in the city field.
>>
>> You can find a first idea of such an interface and 2 view controller examples
here:
https://github.com/guigarage/validation-playground/tree/master/src/main/j...
<
https://github.com/guigarage/validation-playground/tree/master/src/main/j...
<
https://github.com/guigarage/validation-playground/tree/master/src/main/j...
<
https://github.com/guigarage/validation-playground/tree/master/src/main/j...
>>
>> Cheers,
>>
>> Hendrik
>>
>>
>>
>>> Am 01.09.2016 um 10:14 schrieb Gunnar Morling <gunnar(a)hibernate.org
<mailto:gunnar@hibernate.org> <mailto:gunnar@hibernate.org
<mailto:gunnar@hibernate.org>>>:
>>>
>>> Hi,
>>>
>>> Unfortunately I won't be able to attend JavaOne myself, but still it
should be a great opportunity for members of the BV EG and community to meet and
exchange.
>>>
>>> As per [1] there is a BV 2.0 Hackergarten event scheduled for Tuesday the
20th, led by Michael Nascimento. Thanks for taking this initiative, Michael!
>>>
>>> Interesting things to discuss and explore might be proposals written by then
(e.g. the one around List<@Email>, Emmanuel is working on updating this one) and
things like ordering of constraints (BVAL-248, [2]) or David Blevins' proposal around
using Lambdas (BVAL-515, [3]). David should be there, so make sure to get hold of him :)
>>>
>>> Another interesting topic is integration with other specs/techs (e.g.
javax.money or JavaFX). Specifically, there are several pending issues around the
integration of BV and JAX-RS:
>>>
>>> * Provides means to disable BV during JAX-RS lifecycle validation (BVAL-520,
[4])
>>> * Provide facility for more flexible HTTP error codes when using BV with
JAX-RS (BVAL-518, [5])
>>> * Pass the request locale to BV's MessageInterpolator
>>>
>>> Mostly these things would have to be done on the JAX-RS side, so it would be
great to have a chat with them if there is the chance for it.
>>>
>>> Apart from that, essentially anything would be great which helps with forming
a picture of the community's needs and requirements.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>>
>>> --Gunnar
>>>
>>> [1]
http://linkis.com/community.oracle.com/bhe4K
<
http://linkis.com/community.oracle.com/bhe4K>
<
http://linkis.com/community.oracle.com/bhe4K
<
http://linkis.com/community.oracle.com/bhe4K>>
>>> [2]
https://hibernate.atlassian.net/browse/BVAL-248
<
https://hibernate.atlassian.net/browse/BVAL-248>
<
https://hibernate.atlassian.net/browse/BVAL-248
<
https://hibernate.atlassian.net/browse/BVAL-248>>
>>> [3]
https://hibernate.atlassian.net/browse/BVAL-515
<
https://hibernate.atlassian.net/browse/BVAL-515>
<
https://hibernate.atlassian.net/browse/BVAL-515
<
https://hibernate.atlassian.net/browse/BVAL-515>>
>>> [4]
https://hibernate.atlassian.net/browse/BVAL-520
<
https://hibernate.atlassian.net/browse/BVAL-520>
<
https://hibernate.atlassian.net/browse/BVAL-520
<
https://hibernate.atlassian.net/browse/BVAL-520>>
>>> [5]
https://hibernate.atlassian.net/browse/BVAL-518
<
https://hibernate.atlassian.net/browse/BVAL-518>
<
https://hibernate.atlassian.net/browse/BVAL-518
<
https://hibernate.atlassian.net/browse/BVAL-518>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
<mailto:beanvalidation-dev@lists.jboss.org>
<mailto:beanvalidation-dev@lists.jboss.org
<mailto:beanvalidation-dev@lists.jboss.org>>
>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
<
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org <mailto:beanvalidation-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
<
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org <mailto:beanvalidation-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
<
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>