liberate modelMap from TreeStore

When filling the TreeGrid with child items i need to use;

Code:

---

public void addChildItem(M pParentItem, M pItem)

---

This pParentItem is already in the Tree and i don't want to make a new expensive version just to specify a parent. Instead i want to lookup the current available pParentItem by its key. TreeStore contains method;

Code:

---

protected Map<String, TreeModel> getModelMap()

---

After extending TreeStore with my own version i could use this method to get the modelMap which gives acces to the pParentItem model (modelMap.get(key)). But there's a inconsistency in this source code; while getModelMap() is protected it's return type TreeModel is private preventing acces to this modelMap.

I my opinion this TreeModel in TreeStore should also be protected and not private...

This is fairly deliberate - when rewriting the TreeStore for GXT 3, the approach I took was targeted for performance (add operations while sorted or filtered), so makes many assumptions about the internal state of the tree and tree models. There are a variety of assert statements that come with messages - these are meant to inform a user of GXT that an assumption of the API has been violated, while still allowing these checks to be compiled out for prod mode, and there are also asserts with no messages - these are internal consistency checks, meant only to make sure that all internal methods function exactly as expected, and should not be possible to violate externally.

TreeModel is the basic sub-tree structure inside the TreeStore, and is responsible for most of the actual heavy lifting of the TreeStore - adding, removing, filtering, and sorting operations almost entirely happen within it. Each of these cases gets a little hairy when trying to ensure that the assumptions of parent nodes and child nodes are maintained. This class implements TreeNode<T>, which represents just the read-only structural details, and is not permitted to make changes to the internal shape of the tree, to ensure that all changes are verified by the assertions in the TreeStore. For example, if one could run TreeModel.addChild or TreeModel.addChildren externally, without interacting with the TreeStore itself, the TreeStore.modelMap wouldn't be kept consistent, as TreeModel assumes that by the time a call gets to it, the modelMap is already set up (and assertions run) by wrap(M).

Based on this background, I think that getModelMap() also should have been private - it appears it was changed to private as part of a set of changes that were later reverted, though it looks like this one was missed.

Okay, so what options do you have to achieve what you are after:
Want to find the parent model based only on a key? Use TreeStore.findModelWithKey(String) to read it out. I think this is really what you are after, since you probably already know something about the parent you are looking for. Also: iterating through the modelMap is no better than iterating through the entire tree - both are the same size.

Want to work around our use of private to build a faster implementation of something we are doing? Use JSNI - identify the specific invocations you need to make, perform them in JSNI which totally ignores all things private and final, and then be sure you run in dev mode to make sure no assertion errors happen, etc.

Quote:

---

Want to find the parent model based only on a key? Use TreeStore.findModelWithKey(String) to read it out. I think this is really what you are after, since you probably already know something about the parent you are looking for.

---

Hello Mark, indeed findModelWithKey() is what I need for my implementation B)

Thanks!

I'm not sure who Mark is, but if you click the "Mark Best Answer" link, it will highlight it for the next user who has the same issue.

Glad this worked for you.