Requirements
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 (weak 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 preserve the functionality we had in view XML (correspontingView, using fields from modelView, etc/) but we would also like to have columns that are supplied by the query.
<component type="grid" name="orderGroups" reference="grid"> <option type="column" name="number" fields="number" link="true" /> <option type="column" name="name" fields="name" link="true" /> <!-- suggested option for an column from a custom dataset, the main entity must always be in the 0 column index --> <option type="column" name="ordersCount" datasetColumIndex="1" /> <option type="column" name="dateFrom" fields="dateFrom" /> <option type="column" name="dateTo" fields="dateTo" /> <option type="order" column="name" direction="asc" /> <option type="correspondingView" value="orderGroups/orderGroupDetails" /> <option type="correspondingComponent" value="form" /> <option type="searchable" value="name,number,dateFrom,dateTo" /> <option type="orderable" value="name,number,dateFrom,dateTo" /> <option type="fullscreen" value="true" /> <option type="multiselect" value="true" /> </component>
loadOrderGroups(viewState) { grid = viewState.getComponentByReference("orderGroupsGrid"); // standard or expanded Hibernate or JPA criteria builder criteriaBuilder = someService.getCriteriaBuilder(); criteriaQuery = criteriaBuilder.createQuery(); from = criteriaQuery.from("orderGroup"); min = criteriaBuilder.min(from.get("orders")); // the 'modelName' entity must be always first criteriaQuery = criteriaQuery.multiselect(from, min); // this would apply criteria from the grids filter but not pagination yet criteriaQuery = someService.applyGridFilterCriteria(criteriaQuery, grid); query = someService.createQuery(criteriaQuery); // list() dosn't fetch data from the db, it just prepares the list // object which in fact is a proxy to the database datasetSize = query.list().size(); query.setFirstResult(grid.getFirstResult()); query.setMaxResults(grid.getMaxResults()); // the first get from the list will actualy call select on the db // remember that in this case this is actually a List<Object[]> grid.setDatasetPage(query.list()); grid.setDatasetSize(datasetSize); }