BTW I don't know when the properties have been added to URL, but if it's still
possible, I'd use an array on protocol, host, port to be able to do:
@URL(host={"hibernate.org", ""www.hibernate.org"})
On 11 avr. 2012, at 10:52, Emmanuel Bernard wrote:
> Hi all,
> Hardy, Gunnar and I started a discussion that is worth more Eyeballs.
>
> It started after the addition of a `regexp` attribute on @Email to be able to
> restrict the shape of the email via an extra regexp.
>
> Here is the exchange
>
>> Emmanuel:
>> I don't understand. Is this feature different than
>>
>> @Email @Pattern("regexp")
>>
>> If that's different I have not found how. If it's not I don't see the point
>> in adding complexity to @Email.
>
>> Hardy:
>> The difference is that you only have a single annotation. Internally you are
>> using composing constraints (so not really adding much complexity)
>> and report as single violation (which is probably where the advantage lies).
>>
>> It is probably a matter of taste whether you prefer a single @email
>> annotation or @email and @pattern.
>
>> Emmanuel:
>> Also it makes for much less readable code which is something we have
>> constantly discouraged.
>>
>> What reads better @Email(regexp="^((?!\\.org).)*$") or
>> @SomeEmail(excludeTld="org"). Granted, one need to write
>> an custom annotation but readability is much different. I leave it as an
>> exercise to write the same samples if 5 TLDs
>> need to be excluded :)
>
>> Hardy:
>> @email(regexp="^((?!\.org).)*$")
>> You must admit, this is a little bit of a special case. I stumbled across
>> this when looking for negating regexp.
>>
>> Granted, one need to write an custom annotation but readability is much
>> different.
>> in this particular case you might be better off w/ a custom constraint. A
>> more common use case would be to restrict to your
>> own subdomain
>
>> Gunnar:
>> I think we're basically offering users several options/styles here from
>> which they may chose the one they like best.
>> I see use cases where a custom constraint isn't worth the efforts and having
>> the additional pattern restriction within the
>> @Email constraint might be preferable over expressing it via a separate
>> @Pattern constraint.
>>
>> It's also a good thing IMO to be consistent with @URL where we have a
>> regexp() attribute as well (see HV-406).
>
> To reply to this thread and in particular Gunnar, let me expand a bit.
> Hibernate Validator and to a certain extend other Hibernate projects
> have been designed to improve developer productivity not improve choice of
> style. Choice of style is an important reason why the Java
> web stack is so complex to build an application. I don't want to be
> responsible for adding garbage.
>
> 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
>
> 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.
>
> If we go back to our example, @Email(regexp=""^((?!\\.org).)*$") is not
> really 5 nor even 2 times better than @Email
> @Pattern((regexp=""^((?!\\.org).)*$")
> And frankly, regexp is about the less readable construct in the history of
> programming languages. I am not against some functional flags to
> restrict the domain, ensure that it's an email address reachable from the
> internet etc etc as this can be made very readable and clearly
> adds over a mix of @Email + @Pattern. And I also dislike @URL.regexp for the
> same reasons.
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
