Menu
▾
▴
#1240 Support Map in FieldComparator
Auto-sorting, e.g. in listheader using sort="auto(property)" only works on bean-like classes.
If data comes from a generic data source, a Map<columnName, value> would be a typical representation.
FieldComparator could easily deal also with this kind of type by calling get("property") if the underlying object is a Map.
Change would be around org.zkoss.lang.reflect.Fields.get(Object obj, String name);
Let me add some more details on my use case. The Listbox model is a List<HashMap<String, Object>>.
The configuration <listheader ... sort="auto(property1)"/> leads to the following exception when clicking on the header:
>>java.lang.NoSuchMethodException: class java.util.HashMap: name=property1 args=null
>> at org.zkoss.lang.Classes.myGetAcsObj(Classes.java:954)
>> at org.zkoss.lang.Classes.getAccessibleObject(Classes.java:882)
>> at org.zkoss.lang.reflect.Fields.get(Fields.java:116)
>> at org.zkoss.lang.reflect.Fields.getByCompound(Fields.java:63)
>> at org.zkoss.zul.FieldComparator.compare0(FieldComparator.java:121)
>> at org.zkoss.zul.FieldComparator.compare(FieldComparator.java:84)
Sometime some lines of code say more than 1000 words :)
The feature request would be solved by the following lines of code in the beginning of org.zkoss.lang.reflect.Fields.get(Object obj, String name):
if (obj instanceof Map) {
return ((Map)obj).get(name);
}
A listbox with default FieldComparator sorting which fails on a model accepted by databinding
I hope, you don't mind that I refreshed this issue and updated the header fields.
I still consider it a limitation, that I can use a generic data model (List<Map<String, String>>) in a list box with databinding, but I cannot enable the built-in sorting, because this can only deal with bean properties.I upl
I attach a ZUL file which illustrates this problem.
In my opinion, the problem is in Fields.getByCompound() method, which supports only beans by unconditionally calling Fields.get() in the expression node traversal.
In contrast, the DataBinder class checks for Map before calling Fields.get(), e.g. in fetchValue(), or - vice versa - calls Fields.get first and tries then with Map in the catch block as in setBeanAndRegisterSameNodes().
So I wonder, if it wouldn't be better if getByCompound() should not do the same as DataBinder, so any combination of beans and maps would work, e.g. expression "a.b.c" could be evaluated by a.get("b").getC().
And if this modified version of getByCompound() (or a variant of it) would be called by FieldComparator, the issue above would be solved.
Moreover, it also offers the possibility to evaluate databinding expressions from Java, which could be also a nice feature.
http://tracker.zkoss.org/browse/ZK-14