Friendly Property Names for Validation Error Message?

[steve_smith]

I make property "stefanoBestCoolGuy" in my domain object. Then I bind to a Form on a dialog. In messages.properties, I add this:

label.stefanoBestCoolGuy=Stefano:
So, on Form, I get nice label "Stefano:" for my field. Now I add alphabetic constraint to property. When I type in non-alpha character, I get validation error message in dialog message area: "Stefano Best Cool Guy must consist of alphabetic characters only."

I scratch my head and wonder why it not say "Stefano must consist of alphabetic characters only." (because label is "Stefano:"). First I deduce that "Stefano Best Cool Guy" string is derive from my property. This is acceptable sometimes but not other times if make cryptic property name like all cowboy programmers, example, "stefanoBCG". :evil:

Then I realize a few minute later that I can add this in message.properties: "stefanoBestCoolGuy=Stefano". It worked! Now I see message "Stefano must consist of alphabetic characters only."

Suggestion to Keith is for adding namespace for such "friendly" property names in messages.properties. What I mean is, labels have "label" namespace in messages.properties. Maybe you should add support for namespace like "propertyNameInValidationMessage" for these friendly property names. This way, maybe is less confusing when looking at messages.properties. Example,

"propertyNameInValidationMessage.stefanoBestCoolGuy =Stefano"

What you thinking about this one?

[Keith Donald]

Yes, namespaces are needed.

Likely <propertyName>, <label>.<propertyName>, possibly <type>.<propertyName> and <label>.<type>.<propertyName>.

Hell make it configurable...

[oliverhutchison]

Does it make since to place an abstraction for this on top of the existing property registry support? It would be great if we could have pluggable "property" sources. For instance a BeanInfo source, a MessageSource source etc...

I have a reporting system which pushes new reports out to the clients as required; this means that I need a way to dynamically add and remove label/form/icon etc properties. Currently I have a custom subclass of StaticMessageSource that acts as the parent to the standard ResourceBundleMessageSource but this is IMO quite hacky. I'd much rather be able to install a custom property source that directly interrogates the report metadata. I guess I could implement a MessageSource that maps the message key directly to the metadata...

Ollie

[Keith Donald]

Ollie,
I see what you're saying, yes this really does make sense.

So like a PropertyMetadataSource, right -- where things could be like getDisplayName(), getIcon(), getDescription(), isReadable(), isWriteable(), getType() ---- or should the type metadata be separate from the visual metadata?

Would would your PropertyMetadataSource interface look like? This?



public interface PropertyMetadataSource &#123;
public PropertyMetadata getMetadata&#40;String propertyName&#41;;
&#125;

public interface PropertyMetadata extends DescribedElement, VisualizedElement &#123;
Class getType&#40;&#41;
boolean isReadable&#40;&#41;;
boolean isWriteable&#40;&#41;;
PropertyConstraint getConstraint&#40;&#41;; // possibly, for validation?
PropertyEditor getTypeConverter&#40;&#41;; // possibly, for type conversion?
&#125;


Can metadata vary based on context?

Does a PropertyDescriptor suffice for PropertyMetadata or do we need our own info object?

Keith

[SCWells72]

I'm using Spring RCP in an application that is quite configurable by end customers for Swing- and Web-based UIs. We have our own namespacing scheme in place already that correlates message catalog entries to view/property combinations for various uses, e.g.,:

<view-name>.<property-name>.Label
<view-name>.<property-name>.Column
<view-name>.<property-name>.Tooltip
etc.

where <view-name> is a well-known name for a view in the system (e.g., Swing.MyObject.Summary) and <property-name> is a PropertyUtils-compilant property name, possibly nested, mapped, indexed, or all of the above.

I've been able to convince Spring RCP to follow our convention for labels by overriding AbstractFormBuilder.getLabelFor(). Now I've started to add validation constraints and I'm seeing what Stefano was seeing where the message key that is the "name" of the property must be the property name itself with no other components. I would much prefer that I could control this similar to getLabelFor() to allow the validation property stem to be:

<view-name>.<property-name>.Name

or something like that. Any chance of this working today and I just can't find it? Any chance of it going this way anytime soon? Even better, since my labels are the same as what I want displayed in validation error tooltips, can I just configure it to use my getLabelFor() override somehow?

Thanks,
Scott

[adepue]

I'm running into these same issues as well. In our case, property labels can change based on context, so a simple "label.propertyName=..." is not good enough. Either having an interface that provides labels (and other such strings) for properties or a more flexible label namespace would solve our needs. By more flexible namespace, I mean, search for a form specific label namespace before defaulting to the generic label namespace. For example, search for "myForm.label.propertyName", and failing that, "label.propertyName". However, I'd probably prefer a label-providing interface (with an implementation that happens to work as described). But I'm not picky... I'll take anything that works in the end, if it's reasonable. :)

- Andy

[oliverhutchison]

I've just committed preliminary support for providing your own strategies for providing labels, names, icons etc for form properties. The core classes are FormPropertyFaceDescriptor and FormPropertyFaceDescriptorSource and the default implementation is MessageSourceFormPropertyFaceDescriptorSource.

Note that the default implementation is not backwardly compatible as I've changed the format for message keys so that there're consistent with command face definitions. Specifically where you would have had keys like:

label.{propertyPath}=&Some Property
{propertyPath}=Some Property

you should now have:

{propertyPath}.label=&Label
{propertyPath}.displayName=Some Property

or if you want:

{formId}.{propertyPath}.label=&Label
{formId}.{propertyPath}.displayName=Some Property

Please have a look at the changes and feel free to suggest any improvements you can think of. There's also some support for marking individual form properties as read only or disabled - check out FormPropertyState (I need a better name).

Ollie