Oki Carlos, I see your point. For the simple List, Map, Enumeration or Set you
are perfectly right.
But this can easily become a solution which tries to solve even more complex
solutions. For example if you have such a
List<String>
where 1 entry must be a valid email, and another one must be a valid status
string, whatever... See what I mean? So people will start whining "hey we now
can validate that all strings are emails, but we additionally need a way to
only say that half of the strings must be valid emails...".
For the List problem, what about meta annotations?
We have an additional @ListValidation marker flag and by writing
@Email
@ListValidation
public @interface EmailList {}
bval knows then that EmailList is the List<x> version of an @Email validation.
So if you have a
public class MyBean {
@EmailList
private List<String> emails;
If the validation annotation has some payload, then the list validation must
provide exactly the same.
just a weird idea...
LieGrue,
strub
--- Carlos Vara <[email protected]> schrieb am Fr, 7.5.2010:
Von: Carlos Vara <[email protected]>
Betreff: Re: An interesting post about validating collections
An: [email protected]
Datum: Freitag, 7. Mai, 2010 17:54 Uhr
IMHO it isn't business logic, but a pretty valid concern about something that
the standard cannot currently solve.
To explain myself, take the example given in Hibernate's blog, if emails
weren't stored in a String but on their own class, we already have a solution
with @Valid.
public class User {
@NotEmpty
private String name;
@NotEmpty
@Valid
private List<Email> emailList;
}But if you want to validate a type which you cannot annotate, there is no
"clean" way of doing it. Solving it by writing a custom validator like
@ListOfEmailStrings (which is what I have been doing atm) is not a good
solution as you have to replicate the validation logic of all the annotations
that the individual email has.
To put this in perspective, if a single email was annotated like this:
@NotNull
@Email
String email;
The custom validator for the list of emails will have to replicate the
validation logic of those two constraints (as it should never instantiate the
validators), and it would also have to be manually mantained to always validate
your definition of an email.
I personally think that implementing the first solution is a clean way of doing
it and fits the role of the library. Of course, that involves waiting, but
waiting to be able to do something right is never bad in my book :-)
I hope that Hibernate guys don't rush a suboptimal solution like the other ones
exposed, as it would be a clear point of incompatibility with Apache's version.
Regards,
Carlos
On Fri, May 7, 2010 at 3:19 PM, Gerhard Petracek <[email protected]>
wrote:
we are currently discussing it in the eg.maybe we should just wait for [1].
regards,gerhard
[1] http://openjdk.java.net/projects/type-annotations/
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/7 Mark Struberg <[email protected]>
I honestly think this goes into the wrong direction.
This is business logic, and if we start to provide annotations for all those
kinds of problems, it will end up getting terribly complicated.
I'd prefer to keep it simple and stupid.
LieGrue,
strub
>
>Von: Carlos Vara <[email protected]>
>An: [email protected]
>Gesendet: Freitag, den 7. Mai 2010, 10:57:11 Uhr
>Betreff: An interesting post about validating collections
>
>http://in.relation.to/Bloggers/AValidationStickler
>
>Currently as an user, I was solving this by writing custom validators, which
>it seems is no more of a hack than the other proposed solutions (except the
>one that implies waiting for JDK7 to hopefully implement JSR-308).
>
>Any of you guys have an idea of how we could implement it?
>
