[hibernate-dev] [HV] Design philosophy

[Gunnar Morling]

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 <emmanuel at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev