Enhancement: Better behaviour for grouped ListGrids (offload of work to server)

[Blama]

Hi Isomorphic,

I have a suggestion similar to my New API suggestion: ListGridField.setSortField(String sortField)-suggestion.

When grouping ListGrids, you should add the groupBy field(s) as prefix to the sortFields. This should be done iff no GroupValueFunction is applied (and the bare value is used).
You could also add a declarative ds.xml field-setting like the suggested "sortByField" from the thread above (then named "groupByField").

Reason:
When doing so, you can guarantee that a group that is shown as "finished" by the fact that a new group starts, is really finished.
Therefore you can drop the ListGrid.setGroupByMaxRecords()-setting in this cases, as all sorting is already done by the server.

I'm not sure how this should be handled when a GroupTitleRenderer is used, because the position of every group is dependent on its title. This can't be done without client side logic, then, most likely leading to the same problems that made you introduce setGroupByMaxRecords().

Do you think this is a good enhancement (it has no priority for me, but I thought about it again after reading this post)?

Best regards,
Blama

[Isomorphic]

We're not really following this. You seem to be suggesting that just sorting the records on the server side would produce a mode somewhat similar to grouping. While it's true it would show the records in a similar order, it would not provide expand/collapse, cascading selection, grouping by custom functions or anything like that.

It is possible to build a grouping behavior that uses load on demand for each individual group, and would be able to handle a virtually unlimited number of records, based on our recently added support for data paging within folders. This doesn't currently appear on our near term roadmap, and would be a moderately large Feature Sponsorship.

[Blama]

Hi Isomorphic,

I wanted to show a way of achieving what you described in:

and would be able to handle a virtually unlimited number of records

Of course you'd still have to add expand/collapse, cascading selection an so on (grouping by custom functions would not be possible), but the hardest part (the sorting (I hope I'm correct on this one)) would be done by the server.

It's great that you have an even better solution on your list for far-future development so that this is not forgotten. As I wrote it does not have priority for me.

Best regards,
Blama

[Isomorphic]

The sorting is actually the most trivial part. The other points you mentioned, especially expand/collapse and mapping between client and server rownums, are what makes this a hard problem.

[Blama]

Hi Isomorphic,

I meant in terms of compute time, not development time for the functions. Compute time is the reason that there is a setting like ListGrid.setGroupByMaxRecords() in the first place, isn't it?

Best regards,
Blama

[Isomorphic]

No. Loading too much data to the client-side is the primary reason for that setting.

[Blama]

Hi all,

I just noticed that the enhancement made it into 5.0p as ListGrid.setSortByGroupFirst(). From the docs, this method seems to do exactly what I meant.

Best regards,
Blama