Behaviour for commit operation

[julicrack]

Hi,

I would like to change the default behaviour for commit operation when using internacionalized properties. So instead of calling the setter method directly I need to call a custom method aware of the language to be set.

Suppose this example,

class MyClass {
   private Translation translatedProperty;

   public setTranslatedProperty(String value, Language language) {
      translatedProperty.setValue(value, language);
   }
}

There isn't a setter method for "translatedProperty", the domain provides the method above. I suppose a new propertyAccessor is needed but I can't figure out how can I implement it?

I have spent a lot of time trying to solve this issue but in this point I request your collaboration, thank you very much!

[julicrack]

In other words, what is the best way to register a custom PropertyAccessor for properties of a specific type (Translation)?.

Thank you

[LievenDoclo]

Just to be completely clear, are you trying to i18n your API (and not just the messages?)?

[julicrack]

Just to be completely clear, are you trying to i18n your API (and not just the messages?)?

Yes, that is.

I have a requirement consisting on making internacionalizable some attributes of my domain entities. So, we have created a custom type (Translation) aware of the language to be set (Language) , with these methods:

• Translation#setValue(String value, Languag lang);
• Translation#getValue(Language lang);

My idea is to add a value model to the formModel referring the internacionalized property. This value model holds a String object.

Any suggestion?

Thank you very much

[LievenDoclo]

So you have a property like:

private Translation description;

Translation then holds a Map I suppose, matching values with Language?

Is the value dependent of the current Locale of the user? If so, you could easily create a getter getI18NDescription() which returns the value for the current language.

Otherwise you could write a Binder for the Translation type, which enables you to enter translations (for example, an editable list comprising of a combobox field with languages and a string field).

I'm just freewheeling here, so if anyone else sees another solution, feel free...

[julicrack]

Translation then holds a Map I suppose, matching values with Language?

OK

Is the value dependent of the current Locale of the user? If so, you could easily create a getter getI18NDescription() which returns the value for the current language.

No, this is a backoffice interface where the user should fill values in multiple languages. So, the unique way to know the language to be set is in the client classes.

Otherwise you could write a Binder for the Translation type, which enables you to enter translations (for example, an editable list comprising of a combobox field with languages and a string field).

That was our first approach, but the user prefers to use a global language for each form because of selecting the language for each attribute is quite tedious.

I'm just freewheeling here, so if anyone else sees another solution, feel free...

Thank you very much indeed, if there isn't other solution we'll develop the suggested one.