suggestions for validator API

steeven · **Joined:** Tue Jun 21, 2005 10:44 pm **Posts:** 9

I found validator api pretty easy for users. but I have some problem on i18n. here is my suggestion:

Code:

@Max(value=365)
public int getDays(){
   return days;
}

the validate result will be : days must less than or equal to 365

when i need chiese information for user, I wrote following code:

Code:

@Max(value=365,[b]message="{max}{value}") [/b]
public int getDays(){
   return days;
}

the validate result will be : days 不能大于 365

but the user want translate days to chinese words, after I researched the source code, I made some change to ClassValidator:

Code:

private static String getPropertyName(Method getter) {
   Description desc = getter.getAnnotation(Description.class);
   if (desc!=null)
      return desc.value();
....
}

the property name was retrieved from @Description annotation.

I think the @Description is very important for auto layout or reportting.

the message format was some strange for users, is it possible to replace with Java's parametered formatting?

best regards,
steeven

steeven · **Joined:** Tue Jun 21, 2005 10:44 pm **Posts:** 9

btw, Default message should be placed to resource file, so I don't need to place message on every validate annotation.

if possible , replace property files to xml, property files is not user-friendly.

regards,
steeven

steeven · **Joined:** Tue Jun 21, 2005 10:44 pm **Posts:** 9

another suggestion:

title of property may be retrieved from resource too. it is very usefull for me now!

also, @Description.value may be replaced for special case:

Code:

private String getPropertyName(Method getter) {
   Description desc = getter.getAnnotation(Description.class);
   if (desc!=null)
      return replace(desc.value(),null);
   ...
}

emmanuel · **Posted:** Fri Aug 12, 2005 5:21 am

I don't fully understand what you try to solve.
Does that help ? http://opensource.atlassian.com/projects/hibernate/browse/ANN-35#action_19328

jesusaplsoft · **Posted:** Fri Aug 12, 2005 5:13 pm

I made similar suggestions, among others, based on other post from Steeven in atlassian number 35 as Emmanuel says, but he has already decided to reject this proposal though I coincide with Steeven in the way it may be used... and for me particularly is very usefull. Besides I proposed to integrate it into Invalid bean in order to get a field description besides an error...

emmanuel · **Posted:** Sat Aug 13, 2005 12:08 am

OK I get it, but still -1, your usecase is covered by the following

Code:

    @Column(
        name = "ID_BANK",
        precision = 4
    )
    @Max(
        value = 9999,
        message = "{bankId.annotations.max}"
    )
    @Min(
        value = 1000,
        message = "{bankId.annotations.min}"
    )
    private java.lang.Short bankId = null;

bankId.name=Bank Id
annotations.min=Min size of {value} has not been reached
annotations.min=Max size of {value} has not been reached
bankId.annotation.min={bankId.name}: {annotation.min}
bankId.annotation.max={bankId.name}: {annotation.max}

Plus, its more flexible since language doesn't no always set the property name at sentence head.

jesusaplsoft · **Posted:** Sat Aug 13, 2005 6:06 am

This way you work a lot to get the same results:

Code:

    @Column(
        name = "ID_BANK",
        precision = 4
    )
    @Description("{bank.Id}")
    @Max(
        value = 9999,
        message = "{annotations.max}"
    )
    @Min(
        value = 1000,
        message = "{annotations.min}"
    )
    private java.lang.Short bankId = null;


bank.Id=Bank Id
annotations.min=Min size of {value} has not been reached
annotations.min=Max size of {value} has not been reached

This way you have a general message error for every validation annotation

Code:

annotations.min=Min size of {value} has not been reached
annotations.min=Max size of {value} has not been reached

and a particular description of every field using @Description.

This annotation may be involved in:

1. Error message sent to final user.
2. Column name to be used in a Head from a Report.
3. Column name in a tool to compose querys.

To be more practical, Invalid bean returned to user should include description of every field involved in error (supposing it has been given). This way designer can decide its use to compose final error message or not.

Quote:

Plus, its more flexible since language doesn't no always set the property name at sentence head.

I do not know what you mean by this.

emmanuel · **Posted:** Sat Aug 13, 2005 8:10 pm

You have the same separation of generic message and specific message in my solution!

Code:

bankId.name=Bank Id
annotations.min=Min size of {value} has not been reached
annotations.min=Max size of {value} has not been reached
bankId.annotation.min={bankId.name}: {annotation.min}
bankId.annotation.max={bankId.name}: {annotation.max}

Quote:

2. Column name to be used in a Head from a Report.
3. Column name in a tool to compose querys.

This is not the job of a validation framework. You can still keep @Description for you own usage pointing to the same property (eg bankId.name).

jesusaplsoft · **Posted:** Sun Aug 14, 2005 6:26 am

The point is not to make an annotation (@Description) to be used inside validation framework but to be used as field description elsewhere.

This way one can retrieve field description easily using annotations.

IF there is not such annotation, of course, one can always retrieve field description using, e.g., field_name.name in resource file and composing it.

What I was propossing is to use @description (if it exists for any given field and, remember, it is used for some other things...) in returned Invalid bean. This way one has a simple resource file and can construct the returned error for the returned field.

Any way, as I understand your view point: Validator is validator and @Description does not match this framework, one can always use @Description as a private annotation and compose error messages returned using Invalid methods to get access to field @description...

Finally: I had closed this subject as you rejected it previously and I had made my own methods to compose Invalid returned messages BUT Steeven reopened it...
Thanks for your time.