Stripes

Provide mapping for field to UI name in @Validate annotation

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: Release 1.3.2
  • Fix Version/s: Release 1.5
  • Component/s: Validation
  • Labels:
    None

Description

I have the following nested property validation:

@ValidateNestedProperties ({ @Validate(field="name", required=true), @Validate(field="description", required=true), @Validate(field="phenoDataType.dataTypeId", required=true), @Validate(field="phenoUsageType", required=true) })
private PhenoAttributeType selectedTrait;

This results in:

Please fix the following errors:

Selected Trait Description is a required field
Selected Trait Name is a required field
Selected Trait Pheno Data Type Data Type Id is a required field

I can map the fields in the resource file (thanks Tim), but that is limited if two different pages call the same attribute two different things. Also, the Validate annotation is where things are described, so it would be nice to be able to give a replacement string or a localized string right there.

I envision this looking like:

@ValidateNestedProperties ({ @Validate(field="name", required=true, alias="Name"), @Validate(field="description", required=true, alias="Description"), @Validate(field="phenoDataType.dataTypeId", required=true, alias="Data Type"), @Validate(field="phenoUsageType", required=true, alias="Used For") })
private PhenoAttributeType selectedTrait;

This would result in:

Please fix the following errors:

Description is a required field
Name is a required field
Data Type Id is a required field

This matches my labels on the page. Another alternative would be to match the name to the label for this attribute on the page. The nice thing there is that any changes to the label would automatically be propagated to the error message without having to change the annotation.

Activity

Hide
Frederic Daoud added a comment - 17/Jan/08 3:34 PM

If you really need to call the same attribute two different things on two different pages, you could have two different action bean classes, or two different url bindings, and use a different prefix in the resource bundle to distinguish the two...no?

Show
Frederic Daoud added a comment - 17/Jan/08 3:34 PM If you really need to call the same attribute two different things on two different pages, you could have two different action bean classes, or two different url bindings, and use a different prefix in the resource bundle to distinguish the two...no?
Hide
Howard Rafal added a comment - 17/Jan/08 3:42 PM

Absolutely two different action classes would work well. I still like the idea of having the alias or, even better, an alias property because then if I have a field that I use in a LOT of actions, but I have a presentation that is consistent in most cases but has some exceptions, I can still tell a specific common resource for these.

Show
Howard Rafal added a comment - 17/Jan/08 3:42 PM Absolutely two different action classes would work well. I still like the idea of having the alias or, even better, an alias property because then if I have a field that I use in a LOT of actions, but I have a presentation that is consistent in most cases but has some exceptions, I can still tell a specific common resource for these.
Hide
Ben Gunter added a comment - 20/Jan/08 11:04 PM

Fixed for 1.5, although I'm not positive it's exactly what you were looking for. Tim and I had a lengthy discussion about this and decided to do it this way. Added optional element @Validate(label="Some string") to allow developers to easily label an ActionBean property without having to add it to the resource bundle. If a label for the property is present in the resource bundle, it will override this new element.

Show
Ben Gunter added a comment - 20/Jan/08 11:04 PM Fixed for 1.5, although I'm not positive it's exactly what you were looking for. Tim and I had a lengthy discussion about this and decided to do it this way. Added optional element @Validate(label="Some string") to allow developers to easily label an ActionBean property without having to add it to the resource bundle. If a label for the property is present in the resource bundle, it will override this new element.
Hide
Levi Hoogenberg added a comment - 21/Jan/08 6:25 AM

So if I understand it correctly, no attempt is being made to translate the label () value? That'd be even more flexible, IMO. (Background: in a project, we have the requirement of making the resource bundle keys visible for end users, so we can't go for /My.action.property.required.)

Show
Levi Hoogenberg added a comment - 21/Jan/08 6:25 AM So if I understand it correctly, no attempt is being made to translate the label () value? That'd be even more flexible, IMO. (Background: in a project, we have the requirement of making the resource bundle keys visible for end users, so we can't go for /My.action.property.required.)
Hide
Tim Fennell added a comment - 21/Jan/08 7:24 AM

Levi: I don't think we want to do that, at least for now. The goal here is to provide a much simpler way to do things for projects that don't need to localize - they can just keep everything in the bean.

If you really need control over the bundle properties that are used for field names I'd suggest that you log a separate JIRA for it and we'll try and get to it post-1.5. Probably the right way to do that would be to move most/all of the code in LocalizationUtility into the LocalizationBundleFactory (and rename it?) so that you can plugin your own logic to translate bean+field to resource keys.

Show
Tim Fennell added a comment - 21/Jan/08 7:24 AM Levi: I don't think we want to do that, at least for now. The goal here is to provide a much simpler way to do things for projects that don't need to localize - they can just keep everything in the bean. If you really need control over the bundle properties that are used for field names I'd suggest that you log a separate JIRA for it and we'll try and get to it post-1.5. Probably the right way to do that would be to move most/all of the code in LocalizationUtility into the LocalizationBundleFactory (and rename it?) so that you can plugin your own logic to translate bean+field to resource keys.
Hide
Levi Hoogenberg added a comment - 21/Jan/08 8:51 AM

Okay, that makes sense. I was thinking that it'd probably still would be possible to (ab)use the new label attribute by configuring an interceptor that would translate validation errors if possible. I'll think about creating an issue for the more pluggable approach (and will comment here if I do). Thanks for the feedback.

Show
Levi Hoogenberg added a comment - 21/Jan/08 8:51 AM Okay, that makes sense. I was thinking that it'd probably still would be possible to (ab)use the new label attribute by configuring an interceptor that would translate validation errors if possible. I'll think about creating an issue for the more pluggable approach (and will comment here if I do). Thanks for the feedback.
Hide
Levi Hoogenberg added a comment - 21/Jan/08 2:49 PM

Created STS-486.

Show
Levi Hoogenberg added a comment - 21/Jan/08 2:49 PM Created STS-486.

People

Vote (1)
Watch (0)

Dates

  • Created:
    18/Aug/06 6:19 AM
    Updated:
    04/Jan/11 2:48 PM
    Resolved:
    20/Jan/08 11:04 PM