PDA

View Full Version : Need help with forms POJOs and messages properties



gfaerman
Dec 12th, 2004, 02:25 PM
Hi all,

Newbie here.
I have two pojos, class theater, class dog. Both have property called "id".
When displaying the form built with TableFormBuilder (after added the property id with formbuilder.add method) RCP renders the label.id for both classes with the same text.

I need a way to have different values for same name properties of different classes.

Thanks in advance,
Gustavo.

snpe
Dec 12th, 2004, 03:19 PM
You can set id dog and theater for formModel and label are :

dog.label.id
theater.label.id

regards

pdbruycker
Dec 13th, 2004, 01:05 AM
The framework searches for labels in this order:

formId.label.property
label.property
property


So if you have two different forms containing the same business object property, you still can have different labels per form.

Hope this helps,

Peter

snpe
Dec 13th, 2004, 08:24 AM
Peter,
Framework need search nested proeprty like this

formId.label.propertyname
formId.nestedpropertyname.label.restofpropertyname
...
label.lastpartofproeprtyname
lastpartofpropertyname

We can then define proeprty name one and use in anotherr bean (when it is nested)

regards

benoitx
Aug 10th, 2005, 02:41 PM
Hi

I am following the explanation in this note and... it does not seem to work.

The hierarchy in messages.properties as described on the Wiki entry http://opensource.atlassian.com/confluence/spring/display/RCP/Forms+Support?showComments=true#comments
formId.label.property
label.property
property

does not seem to work anymore... I have to add:
property.label=xxxx

for the form to display xxxx for my property.

But how could I specify different labels on different forms?
I tried multiple things:
formId.label.property
formId.property.label
property.label.formId
property.formId.label

So you see that my brain is about to explode....

Anyone got that right with the latest code (Aug 05)?

Thanks
Regards from London!

Benoit.

oliverhutchison
Aug 10th, 2005, 06:53 PM
See MessageSourceFormPropertyFaceDescriptorSource JavaDoc. I'd paste it here but I don't have access to sourceforge at the moment.

Ollie

benoitx
Aug 11th, 2005, 02:55 AM
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


FormModel myModel= FormModelHelper.createFormModel(myObject);

which creates it ok but with a formId being null. This can be rectified like this:


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?

oliverhutchison
Aug 11th, 2005, 05:25 AM
PS: wrt CVS issue, does this mean that development/fixes of SpringRC are 'on hold' until SourceForge fixes it?

No, it just means it's a pain in the ass. I do most of the devlopment at work so now I have to transfer the code to my home computer and then commit to SF.

If you want to make some noise to hurry them up feel free ;-)

Ollie