Enterprise Client Community

We have a problem with a field with a e.g. BigDecimal or Integer.
When the field is set in the bean the chanced value from the ui will successful write into the bean.
When the property in the bean null the ui make a string and give this to the BeanWrapper. ( Controls with the debugger

<t:field id="g_227" attributemacro="BeanWrapper()" reference="expression:#{d.AbholAuftrag.data.abholAuftragWrapper.lademeter}" width="30" />

public java.math.BigDecimal lademeter = null;

Hi,

there is no change to bypass this behaviour, because you use the FIELD (and not FORMATTEDFIELD).

The problem is: the client passes a string "1234", the server now passes this into the application. While passing it tries to find out the best fittin data type. The sequence is:

(1.) If the property is a set/get property, then "Yippieh!" - the data type of the property is defined by the program.

(2.) If the property is a dynamic one, behin a Map implementation, then it is a bit more difficult:
(a.) if there is already a value in the Map, then "Yippieh!" again - the data type of this existing element is the driving one
(b.) if there is no value in the Map, then this data type is chosen which fits best to the component; e.g. if it is a CALENDARFIELD, then a Date is chosen, etc. for FORMATTEDFIELD. For FIELD components there is no data type association behind... - so the last option (c.) is chosen.
(c.) the data is passed into the Map as String

So, this explains the behaviour you describe.

Björn

Sorry, I forgot to write, what you can do:

(1.) Use FORMATTEFIELD with proper data type definition.
or
(2.) Apply a server side data type conversion

Hope this helps!

Björn

Update 20081215 contains a furhter improvement: interface IPropertyValueConverter - this interface is called prior to passing the value - please check the JavaDoc of the interface.

Björn

Thanks for this feature.
It fix the problem with this problem.

Good work!

Greet Wocher