Hi
If you manipulate figures in your project you will likely be using KeyValue entities and their ecosystem in CUBA.
For instance if your KeyValueEntity
datasource is backed by a GROUP BY query like
select e.customer.name, e.status e.date, sum(e.amount) from app$CustomerOrder e group by e.customer.name, e.status, e.date
Then you will probably want to define a KeyValueMetaClass
where e.customer.name, e.date and e.status are copies of CustomerOrder
and Customer
equivalent properties, and potentially named differently.
So it could be useful that instead of building KeyValueMetaProperties manually, the KeyValueMetaClass
is able to copy (map) properties from another meta class.
Now let’s say that in the proposed query e.status
is an Enum. As of now if you call getValue(...)
on a KeyValueEntity
the enum id will not be converted to an EnumClass
like for regular entities.
Sample project attached proposes to help in these 2 areas using enhanced versions for KeyValue{Entity, MetaClass, MetaProperty}.
Example to create meta class for the proposed query:
ExtKeyValueMetaClass mc = new ExtKeyValueMetaClass();
mc.mapProperties(CustomerOrder.class, "client:customer.name", "status", "date", "amount");
This will create 4 KV meta properties including one named ‘client’ mapped to ‘name’ property of Customer
‘customer’ property of CustomerOrder
. Each meta property copies the characteristics ot the MetaProperty it is mapped too, especially the data type. You can of course map properties for several different classes.
You will also see that the proposed ExtKeyValueEntity
converts enum ids to their respective EnumClass instance on the fly.
Using these classes, you make sure that using any KV data source with a visual component will make the property values displayed and formatted exactly like the original properties they are mapped from.
EDIT: fixed the classes as advised by @gorelov
Michael
kvdategrid.zip (117.4 KB)