[bv-dev] Conflict issue with value extraction and JavaFX collection types
Emmanuel Bernard
emmanuel at hibernate.org
Tue Apr 18 08:57:59 EDT 2017
I'm not using JavaFX but I would be in favor of 2. because it let's
people put a size constraint on the List.
Have you considered a blog post to get more feedback. Here people don't
use JavaFX or are shy.
On Wed 17-04-12 16:16, Guillaume Smet wrote:
>Hi,
>
>We are refining the value extraction work and one of the remaining tasks is
>to throw a proper exception if we have ValueExtractors defined in parallel
>hierarchies for a given type.
>
>This led to discovering the below issue with the JavaFX collection types.
>
>Let's take the ListProperty example (we have the same issue with Set and
>Map): ListProperty inherits from ObservableValue and from List.
>
>For now, it uses (by chance) the ObservableValue extractor which unwraps
>the value by default. So basically:
>@NotNull
>private ListProperty<String> listProperty = new
>ReadOnlyListWrapper<String>( null );
>will return a violation.
>
>With the new conflict detection, it will throw an exception as it's unable
>to find ONE most specific ValueExtractor as there are 2 valid candidates:
>ObservableValueValueExtractor and ListValueExtractor.
>
>If we want to solve the conflict, we need to introduce a specific
>ValueExtractor for ListProperty and decide of its behavior.
>
>We have 2 possibilities:
>1/ consider ListProperty as an ObservableValue and thus simply unwrap the
>list and validate the constraint against the list. In the above example,
>@NotNull would then apply to the inner list. Same behavior as explained
>above.
>2/ consider ListProperty as a List. Thus the value extractor would iterate
>over the element of the list. In the above case, it won't return a
>violation. In the below example, the @NotNull would refer to listProperty
>itself and the constraints on the elements of the list would be validated:
>@NotNull
>private ListProperty<@Size(min = 3) String> listProperty = new
>ReadOnlyListWrapper<String>( null );
>
>Gunnar and I are in favor of 2/ but it changes the current behavior as the
>@NotNull would refer to the container instead of referring to the wrapped
>value.
>
>We would really like to have some feedback from people using JavaFX.
>
>Thanks!
>
>--
>Guillaume
>_______________________________________________
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
More information about the beanvalidation-dev
mailing list