TreeGrid.getSelectedState is null while treeGrid.getSelectedRecord() is not null

[michaelplavnik]

I am implementing two level TreeGrid with two columns. First level is marked with node.setCanSelect(false). Also each node has name and title set explicitly. All nodes are opened with tree.openAll().

Upon real time message from the server I am trying to obtain TreeGrid.getSelectedState and getting null while treeGrid.getSelectedRecord() is not null.

I suspect you need some example, but if you can first look into conditions under which state will be null?

[Isomorphic]

getSelectedState() would be expected to return no state in the following circumstances:

- no dataSource, or no PK fields
- no selectionManager
- the [expected selected] record is canSelect false, or is a group node (which would be auto-selected via partial-cascade, if any of its children were selected)

getSelectedRecord() does not require the first of those - so it would return a selected record, even if there was no DataSource, or the DataSource had no PKs.

We're going to update the docs to clarify this, but does that reflect your situation?

If not, we perhaps will need to see some code...

[michaelplavnik]

Thanks for a quick reply. I do not have datasource bound to the TreeGrid, as Tree is build manually. I would think that even without datasource, one can use ID (as PK) if present to build the state (that is what I ended doing). In my case, this is shorter then creating client only datasource :-).

[Isomorphic]

We're not sure what you mean by "ID" in this case. Path to node maybe?

Attaching a DataSource with a PK declaration tells us: this is a persistent unique identifier. Without that, any other possible ID has an unclear lifespan - so for uniqueness we use Object identity.

[michaelplavnik]

If selected node has getAttribute("id") != null it can be used in the state representation. If you tell TreeGrid users that using TreeNode.setID with getSelectedState() on unbound TreeGrid, requires Tree-wide unique identifier they will do it.

[Isomorphic]

The Tree has multiple modes of linking up nodes (see tree.modelType), one of which works as you describe: each node has a unique ID.

Providing a DataSource with a primaryKey declared is the way that you tell the system that the IDs in use are persistent, and so make sense to go in the selectedState. If IDs are not persistent, so for example they are just generated within the page and change each time, then the selectedState should try not to hold onto IDs. So that's why the DataSource makes the difference, even if IDs are in use: it's a matter of declaring them to be persistent IDs.

Note that all you need to do is provide a super simple DataSource with the PK field declared. You do not actually need to arrange for the data to be fetched from the DataSource. Just provide the DataSource and the tree data separately - the DataSource in this case is just a handful of lines of code.