Community
Participate
Working Groups
So far, all the explorers consume selection model regardless of their using selection service or not. Selection model is not only for selections but also for traversing. I am opening this bug to refine the underlying APIs as part of the future exposure of Orion navigator. There are 4 layers of classes we are using for our explorer based traversing/selection. layer 1. A universal tree model traverser, which knows how to traverse a tree/flat list and keep the cursor position. layer 2. A universal dictionary model, which is completely separate form tree model. The dictionary uses a tree node model id as key. The value of a key is an object referencing the visual presentation of the tree node(e.g. A row DOM node, grids o n the row). layer 3. Selection service, which holds a list of selected model references. layer 4. An explorer based navigation handler class, which consumes layer 1&2 and talk to layer 3. It listens to all the key events on the explorer's parent DIV and mouse events on each row. It asks layer 1 to traverse and layer 3 for selection. It uses layer 2 to manipulate cursor and selection highlighting. Layer 1,2,3 are quite solid and not limited to explorers. We just need a better documentation. I think we still need to improve layer 4 in terms of the selection model life cycle and selection policy. Life cycle: 1. When we create an explorer tree, we create an empty dictionary(layer 2) before the tree starts rendering. Later on we ask the render to register the value for each row. We need a better timing to empty the dictionary and refresh it during row changes. Otherwise expand/collapse will make a lot of entries in the dictionary useless. 2. On any row change, we lazy create a navigation handler(layer 4) and refresh the handler by asking model.getRoot(). This may be time racing in some cases. Selection policy: We now have 3 flavors of selection/traversal. 1.Full selection. Any row is selectable. Examples: file navigator, git log. 2.Mixed selection. Some rows are traverse-able but not selectable. Examples: Unstaged and staged sections in git status page. The traversing to the widget row does not change selection may surprise user: "I did not press ctrl key when I press down arrow key, why it did nto move selection?" 3.Travers only. No selection at all. Only to trverse. Examples: Search page, changes section in git commit page. 4.Container based selection. This part is totally uncertain yet. Examples: Replace page. Using traverse only + check bok. We really need a better design on this for RCs.
bug 382428 talks about multiple selection changes after changing navigator root. We should consider this to be fixed after the life cycle is improved.
Also we should not require explorer model have the .children and .parent properties. We should use the existing getChildren and ask for a new fucntion getParent. There are several places we are requiring this: Search page, string externalizer page, navigator page, git status page, git commit page. Basically all the pages that what arrow keys to drill in should provide getParent.
In the review of bug 382538, I realized the importance of the dictionary(class layer 2 & life cycle 1)). I think the dictionary reference should be accessed by the treeTable level in order to update and use it. The dictionary already has the object as the value of a model with its id as the key. This object already contains some DOM node refs which can completely replace the dojo.query for the job. We should replace dojo.query with a wrapper function asking the dictionary for a row DOM node. If this cant do the equivalent job as dojo.query does, that means the dictionary is not built up properly.
(In reply to comment #2) > Also we should not require explorer model have the .children and .parent > properties. We should use the existing getChildren and ask for a new > fucntion getParent. > There are several places we are requiring this: > Search page, string externalizer page, navigator page, git status page, git > commit page. > Basically all the pages that what arrow keys to drill in should provide > getParent. I ran into this very problem when I tried to start using explorers in the outliner (bug 359480). I had to do something like this: OutlineModel.prototype.getChildren = function(parentItem, /* function(items) */ onComplete){ if (parentItem.children) { // The tree model iterator assumes that there are back links to the parent for (var i=0; i<parentItem.children.length; i++) { parentItem.children[i].parent = parentItem; } onComplete(parentItem.children); } else { onComplete([]); } };
Libing, we should probably have a discussion about this bug next week or so, I have similar issues in the explorer/renderer space, and it would be useful for us to visit things like the "id/item" map, etc. holistically.
Triage in 2.0M1.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
