Enterprise Client Community

Hi,

we use t:formattedfield with the attribute "format" set to integer:

t:formattedfield format:int value:#{d.mybean.mymap.mykey} ...

The value, which is entered by the user, is added to the initially empty map "mymap" of the bean "mybean".
The value in the map is associated with the key "mykey".
This all works fine.

Our problem is the type of the object added to the map:
Sometimes it is a java.lang.String, sometimes it is a java.lang.Integer.

Probably this behavior depends on something outside of our application - but we don't know what:
On two of our laptops we get always integers, on two others we get always strings.
One of the "Integer laptops" runs Windows7, the other WindowsXP.
The same is true for the two "String laptops".
It must be something else...

Some months ago we had the same problem with date values.
Sometimes we get java.util.Date, sometimes we get the milliseconds since 1970.

In the meanwhile we have solved the problem by robust data converters.
But it would be nice if the attribute "format" of t:formattedfield would control the type of objects stored in the map in a stable way.

Kind regards,
Markus

Hi,

the rules of data types are documented in the Developers' Guide (Data Type Considerations), esp. for Maps:

(1.) if the Map already has a corresponding item, then the data type of this item will be used in the following
(2.) if the Map does NOTcontain an item then the component is checked for a data type (and int is passed as int)

...and the best approach is to support the interface IPropertyTypeResolver with the Map that holds the data, then the application explicitly controls what type is selected.

We have a couple of tests testing the scenario as described, and we also had a couple of cases, when exactly what you described happend at customer site - always due to Strings in the map... so it always was "data related".

Could you add some checking on data types in your maps. Just override the map in the way:

Code:

 public class MyMap extends HashMap<?,?>
 {
     public void put(...)
     {
        // add here some check logic...
     }
 }

Thanks + regards!
Björn

Hi Björn,

in public void TaskDialogBean.prepare(final IWorkpageStartInfo wpsi) I create a new instance of my LoggingHashMap now.
All calls to this map are logged.

The interesting logged line is:
LoggingHashMap.put(K,V) was called, K = personnelnumber, V = 11223344, V.class = class java.lang.String

The form in the jsp page is dynamically created.
Here comes the part which describes the fields where I have entered 11223344:
t:label width:100+ text:personnelnumber rendered:true
t:coldistance width:2
t:formattedfield format:int value:#{d.genedit.data.personnelnumber} width:100% bgpaint:#{d.genedit.props["personnelnumber"].bgpaint} enabled:#{d.genedit.props["personnelnumber"].enabled} rendered:true
t:coldistance width:10
You find the complete log file and the LoggingHashMap class attached.

Kind regards,
Markus

Hi Markus,

I haven't checked your logfiles it's just a hint how we have overcome a similar issue.

We could solve it by implementing IPropertyTypeResolver.
Code:

 public class ComponentWrapper extends HashMap<String, Object> implements IPropertyTypeResolver
 
   @Override
         public Class resolveType( String key )
         { 
           //return Class for value with this key
          }

I think, if you have a reference to a null value the Class is by default String.class

maybe it helps, kind regards,
Daniel