Hi Ollie,
Many thanks for your post. The JavaDoc is as follows:
An implementation of FormPropertyFaceDescriptorSource that resolves the FormPropertyFaceDescriptor from the MessageSourceAccessor provided to the setMessageSourceAccessor method or from the ApplicationServices singleton if none is provided.
The various properties of the FormPropertyFaceDescriptor are resolved from the message source using message keys in the following order:
- {formModelId}.{formPropertyPath}.{faceDescriptorPr operty}
- {formPropertyPath}.{faceDescriptorProperty}
Where
- {formModelId} is the id of the form model
- {formPropertyPath} is the form property path being resolved
- and {faceDescriptorProperty} is one of displayName, caption, description or label.
If required the strategy for generating these key can be overridden be providing an alternative implementation of the getMessageKeys method.
You were absolutely right, it didn't dawn on me that I had to put the formModelId rather than the "form page" Id (also called formId in AbstractForm). But in a way... I still wonder if it may be valid to define the messages on a per form 'page' basis rather than a model... not sure...
Finally, the PetClinic example uses this way to create the model
Code:
FormModel myModel= FormModelHelper.createFormModel(myObject);
which creates it ok but with a formId being null. This can be rectified like this:
Code:
FormModel myModel= FormModelHelper.createFormModel(myObject,"MyModelId");
And the messages.properties can use:
MyModelId.property.label=My greate label!
Once again, thanks for your post.
Best regards from London!
Benoit
PS: wrt CVS issue, does this mean that development/fixes of SpringRC are 'on hold' until SourceForge fixes it?