Well, if you make a custom hierarchical Grid implementation, you are free to use whatever way to express the hierarchy in the container. In my example code, I just used the getParent() from the Hierarchical interface to get the information.
Using my filtering solution would not be suitable with SQLContainer – you’d definitely need to have a wrapper container that does the filtering by using in-memory expand/collapse states states. EverproTreeGrid seems to use such a wrapper (it doesn’t use the Filterable mechanism but custom item set manipulation) – but it also requires that the container implements Hierarchical, so plain SQLContainer would not do. Also, I’m not sure how efficient (memory or CPU) its container wrapper is, which could be an issue if your query results are huge.
Well, there is
ContainerHierarchicalWrapper
, which purpose is to add Hierarchical interface to containers that do not have it. Well, it’s not Indexed, as required by normal Grid, and not Filterable, as required by my example code, but for EverproTreeGrid it probably would be OK. Also, implementing the Hierarchical interface is not necessarily a big task,
as shown here
.