Right now MetaTypeFactory.resolve(Map[String,?].class) returns a TableMetaType. It seems
more natural for this to be a CompositeMetaType that does not restrict the item names when
the Map has String keys, for example:
| MutableCompositeMetaType expected = new
MutableCompositeMetaType(HashMap.class.getName(),
"HashMap<String,String>");
| expected.addItem("key1", "key1", SimpleMetaType.STRING);
| expected.addItem("key2", "key2", SimpleMetaType.STRING);
| expected.addItem("key3", "key3", SimpleMetaType.STRING);
| expected.freeze();
|
| String[] itemNames = {"key1", "key2", "key3"};
| MetaValue[] itemValues = {SimpleValueSupport.wrap("value1"),
SimpleValueSupport.wrap("value3"),
SimpleValueSupport.wrap("value3")};
| CompositeValueSupport mapValue = new CompositeValueSupport(expected, itemNames,
itemValues);
| MetaValue value1 = mapValue.get("key1");
|
A new MapValueSupport could implement this type of CompositeValue. The
TableMetaType/TableValue seem very awkward for this type of map. Is there a reason not to
support this and require all Maps to be TableMetaType/TableValue?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126829#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...