Hi,
> 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
That's a really valuable catalogue of questions. Is it available in
the Wiki somewhere?
I think it might make sense to have some manifest or charter like this
publicly available, so that we can use it as base for discussions such
as the one at hand, but also as reference for users why we're leaving
out certain feature requests.
Regarding @Email I'm not having a really strong opinion for or against
the change, so I'd also be interested in what others are thinking.
Originally for me consistency with @URL was an argument for the
change, but you're having a good point by asking why regexp() then
isn't added to the other constraints.
On using reg exps in general, I guess their power (and thus
complexity) is their strength and weakness at the same time. So
another idea might be to provide simplified means of specifying
patterns by only using "*" (and maybe "?") as placeholder (as known
from Windows search):
@Email(pattern="*@hibernate.org")
or
@Email @SimplePattern("*@hibernate.org")
I think that's reads pretty well and might be sufficient for most use
cases (and all others could still use @Pattern).
>> 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"})
> Good point. In retrospect this would have been better. Unfortunately, the
> current properties are around since the very first 4.x version.
We might use the opportunity of HV 5 and change this.
--Gunnar
Am 11. April 2012 18:38 schrieb Emmanuel Bernard <emman...@hibernate.org>:
>
> On 11 avr. 2012, at 17:12, Hardy Ferentschik wrote:
>
>>>
>>> To me, it adds complexity :
>>>
>>> - in HV's code but that's not a strong factor in this case
>>> - more doc
>>> - as a user looking at @Email when I use it, I have to understand why such
>>> an option has been added and if I need it
>>>
>>> And I don't see why you don't add regexp to CreditCardNumber, ModCheck,
>>> NotBlank, NotEmpty and SafeHtml. There are "equally valid" use cases for
>>> that. But if you add them to all these annotations, I will start to
>>> question your massive duplication error.
>>
>> I think that's a bit exaggerated, but to be fair you have a point. I
>> personally draw my line in the sand where things stand right now and I am
>> not having any plans to add a regular expression
>> to any of the above constraints.
>
> I was not facetious:
>
> - CreditCardNumer: use a regexp to reduce valid credit cards to specific
> countries or specific bank entities
> - ModCheck: assuming data is stored like credit card numbers (such as bank
> entity), use this data to filter out numbers
> - SafeHtml: filter out some offensive words
> - NotBlank / NotEmpty: not only should it not be empty but it should conform
> to a specific pattern
>
> I agree with you the NotBlank / NotEmpty example is a bit extreme but I think
> the first three are perfectly valid and of the same logic as @URL or @Email.
> _______________________________________________
> 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
