One of the things about support for hierarchical data, is that concepts that apply to flat data become significantly difficult to conceptualize and implement. To put this in context, imagine the good old filtering functionality. With flat data, you have a set of columns, and a filter will apply to one of the columns.

With hierarchical data, this concept becomes more difficult to implement, because now you have to filter out each item that matches a filter, keeping in perspective that its ascendants or descendants may or may not match the filter. So if a child matches a filter, but the parent does not, we would take out the parent, which in essence takes out the child as well. Then you have scenarios where the parent matches, but none of the children do. Even the concept of matching requires thought, because the field being searched on might exist on the parent, but not the child or vice versa, since they could potentially be different object types and might not share the property being searched on. Whew! That was a mouthful.

Since we have to account for these scenarios, we have the following properties:

  • enableRecursiveSearch: For Grouped datagrids(reusePreviousLevelColumns=true), searching on this column will cause match current item, as well as any of its children. If any children match, this item matches as well.
  • enableHideIfNoChildren: Flag to control whether or not an item that has no children is filtered out or not.
  • filterExcludeObjectsWithoutMatchField : By default, for hierarchical datagrids, when there is an object that does not have the property being searched for, these objects are included in the filter match. Set this flag to true to exclude such objects.

It is things like this that we consider to be the strength of Flexicious Ultimate. It’s the fact that we have already thought about scenarios like that so you don’t have to. There are literally hundreds of things like this.

That brings us to the topic of this blog post, the selection exclusion mechanism.

One of the things that we have built into the architecture of the product is the concept of lazy loaded hierarchical datagrids. Data is loaded on demand as the user scrolls (Virtual scroll) or as the item is expanded (Lazy Load, Full and Partial). This all works fine, but what do you do about selection cascade and bubble? So far, (up until 2.5) this was limited to eager loaded grids, so when you check a parent, we run through and automatically select the children, i.e. add them to the selectedObjects collection. The big assumption here is that children are already loaded when you select the parent. This assumption falls flat on its face when you have lazy load or virtual scroll. In scenarios like this, you could select a row, and then expand or scroll. It will also cause performance issues if you have large datasets and you end up selecting a lot of records that cascade selection. Well, say hello to enableSelectionExclusion. From the docs:

enableSelectionExclusion: Support for selection based on exclusion. In scenarios where you have lazy loaded grids, selection cascade and select all will simply set flags on the selectionInfo object. The selectedObjects and selectedKeys no longer contain references to data that is selected. Instead, they contain the items that the user explicitly selected. unSelectedObjects will contain items that the user explicitly unselected. This helps maintain selection across very large lazy loaded datasets. When you set the enableSelectionExclusion flag to true, use the selectionInfo object to access the selection (or build a query on the server) to identify the objects user selected.

The selectionInfo object is a simple list of LevelSelectionInfo objects, which contains explicitly selected and unselected objects, which can then be used to construct a query on the server as to what the selection on the client was.

See the VirtualScrollExample for this concept in action!