Requiorments
As a developers I would like to have the ability to insert a custom dataset to the grid component in a way that would preserve its filter and pagination functionality if possible.
There are many situations listed below in which this might be used. It would be best to create one flexible mechanism to handle them. Even if it would have to make a less comfortable API then usual.
1. Entity centric grids but with some additional calculated columns
For example the orders column in: http://wiki.qcadoo.org/display/QCDMESBLP/Order+groups
We could use an non-persistent field for this. But it would have to do n-queries where n is the number of orders shown in the grid. There are also more complex examples that can follow this with sub-queries and other aggregations.
2. Fully calculated girds
Like the inventory table in: http://wiki.qcadoo.org/display/QCDMESBLP/Inventory+Module
This is a fully calculated view not related with any.
3. Grids with complex filters
4. Grids with datasets calculated in Java
5. Fully with unspecified columns (week requirement)
Like in the module: http://wiki.qcadoo.org/display/QCDMESBLP/Custom+query+module
Suggested mechanism
This is a pseudo-code solution suggested by the person who analyzed the issue. Developers who implement this issue should design the detail solution for the requirements and may come to an solution which is very different from this one. However it should offer the same possibility as the example shown here or if should be discussed if the detail solution could be less powerful to make the implementation simpler.
The solution should be available as an Java API available to hook which would be responsible for preparing the data for a table.
1. Entity centric grids but with some additional calculated columns
Here we still want to