4:14 a.m.
Personally, I wouldn't bother supporting raw collection types. Raw type
usage is discouraged and may even go away in future Java versions IIUC. And
you don't know what value type is in there from looking at the declaration,
so we'd loose the ability to check correct constraint placement at compile
time.
2016-11-23 10:51 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 23 Nov 2016, at 09:06, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2016-11-21 17:08 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers(a)me.com> wrote:
>
> Next to the „applyTo“ value all the constraint annotations needs
> additional information to really validate all the given examples. In
> addition a plugin must be present that defines how we can get the internal
> value(s) of a class (in this case „StringProperty“).
> Here are some code snippets that use additional information in the
> annotations to define the validation:
>
>
> @NotEmpty
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS)
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, applyToInternalDepth =
> 2)
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, applyToInternalDepth =
> 3)
> private List<List<List<StringProperty>>> spooky;
>
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, valueContainerClass =
> RealValue.class)
> private RealValue<String> myValue;
>
> The „applyToInternalDepth“ value is used to define how often the
> validator should get the internal value (depth). In the given example
> „@NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, applyToInternalDepth
> = 3)“ would validate the content of the „StringProperty“. In addition we
> need some information for the container if the container implements several
> interfaces. This could be defined in the annotation, too. In the example
> this is defined by the „valueContainerClass“ value.
>
>
> Hopefully we can converge on my idea not to have to
> add valueContainerClass (see the other emails). But you do need a way to
> identify the correct type parameter targeted. This is equivalent to the
> @ExtractedValue which today has typeParameterHost and
> either typeParameterIndex or typeParameterName to uniquely identify them.
>
> On the depth approach, your example would be more easily rewritten as
>
> @NotEmpty List<@NotEmpty List<@NotEmpty List<@NotEmpty
> StringProperty>>> spooky;
>
> which clarifies everything. But let’s assume we have a type
> ListOfListOfListOfStringProperty type. do we really want to support
>
> @NotEmpty
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS)
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, applyToInternalDepth =
> 2)
> @NotEmpty(applyTo = ConstraintsApplyTo.INTERNALS, applyToInternalDepth =
> 3)
> private ListOfListOfListOfStringProperty spooky;
>
> or even
>
> @NotEmpty
> // support nested levels by positioning ConstraintsApplyTo at the right
> level
> private List<@NotEmpty List<@NotEmpty @NotEmpty(applyTo =
> ConstraintsApplyTo.CONTAINED_VALUES) ListOfStringProperty>> spooky;
>
> Or do we throw the towel and say that nested levels are not supported for
> non parameterized type use locations? What I am realizing now is that this
> option is available essentially to support containers that do not offer
> parameterized type. And in a previous email, I am questioning that use case.
>
I'm also not convinced of this. In a way it seems to me like breaking
encapsulation.
When dealing with a type such as ListOfStringListsProperty, you don't know
it's inner works from a variable declaration. Hence I'm doubting that you
should be allowed to apply constraints to them from the outside. It's
getting more apparent when thinking of more real-world domain-specific
types:
public class CustomerContacts {
List<List<String>> contacts; // one single inner list contains the
contacts valid at a given time
}
I don't think it makes sense to allow application of constraints "from the
outside" when dealing with a property of CustomerContacts. It makes
assumptions on the implementation of that type which is a dangerous thing
to do. What if the implementation of CustomerContacts changes to be
map-based? Existing constraint configurations given at the usage side would
have to be adapted then.
Instead the constraints should be declared within CustomerContacts itself.
It's different for generic types. When dealing with a type like
List<List<String>>, its "inner workings" are apparent to the user,
i.e.
it's reasonable to allow them to apply constraints to the elements of the
inner list for instance.
Ah interesting point of view. I’ve never thought of it that way.
I think what I had in mind when I said containers with no parameterized
type is the Java 4 style collections that only have raw type support.
@Email(validApplyTo=ConsgraintsApplyTo.CONTAINED_VALUE)
Collection emails;
But back to the question, is that even a valid use case in 2016?
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev