On Apr 11, 2012, at 10:52 AM, Emmanuel Bernard wrote:
When adding a feature, we have always implicitly asked ourselves this
pool of questions:
1. Does it feel like the right way of doing things?
If it's not, we have been prone to wait till we mature on the idea. Take
collection element constraints as a good example. We know the right way but
it's not available to us yet
2. Can I do it with an existing construct with similar or less complexity?
3. Is this feature wrong? eg validating unicity with a database query is wrong.
4. Is this a popular request?
5. Is this feature useful in the general scheme? "What's your use case?"
mantra.
6. Is it the most readable approach?
7. Is the feature designed consistently with the rest of the library
+1 agreed
Keeping the library useful and simple is a constant battle against
people wanting to throw new features at it but resisting to the dark side is
important. More than that, I think that's our job to be this gate keeper and we
deserve to be shot in the knee and kicked while on the ground.
We are here to make the world a better place, not give food to guideline writers.
+1 I more than once resisted the dark side
If we go back to our example,
@Email(regexp=""^((?!\\.org).)*$") is not really 5 nor even 2 times better
than @Email @Pattern((regexp=""^((?!\\.org).)*$")
I am not sure how one would measure this leverage factor so I stay out of it. Adding the
regexp is backwards compatible, its optional and hence for most users
not visible. If you are going to need it you have the choice between:
@Email(regexp=""^((?!\\.org).)*$")
or
@Email
@Pattern((regexp=""^((?!\\.org).)*$")
I don't see any harm here. In fact I think that the first version even adds a little
more context information, because it tells me that the main concern is about making sure
that we have an email (meeting an additional validation criteria). In the second case the
@Pattern could also be just replacing a @NotEmpty (depending on the
regular expression of course) constraint.
And frankly, regexp is about the less readable construct in the
history of programming languages.
and one of the most powerful one as well :-)
I am not against some functional flags to
restrict the domain, ensure that it's an email address reachable from the internet
etc etc
I am not against additional flags either, and I was in fact thinking whether a
"reachable" flag to @Email and @URL would make sense. This is something which is
outside
the character based validation. Regarding the domain restriction flag, where do you draw
the line? Do you want a includeDomain, excludeDomain, includeUser, excludeUser,
allowGmail, disallowYahoo, … - or do you rather add a regexp flag?
--Hardy