Community
Participate
Working Groups
Forked from bug Bug 377500. Steps: 1) Open the new status page (git-status2.html) 2) Have some unstaged and some staged changes 3) Select something in the unstaged section, you should see "Stage", "Checkout" and "Show Patch" actions 4) Unselect changes 5) Select something in the staged section, you should see "Unstage" 6) Now leave the selection in the staged section and select something extra in unstaged section You would expect to see "Stage", "Checkout" and "Show Patch" actions again, but that does not happen. I noticed that Selection#setSelections method (in selection.js) always gets all selected items from staged and unstaged sections.
I'll check this out in your new page. Its behavas if the wrong selection service was passed to the explorer, but maybe the command framework is not finding the right one.
The problem here was that we were using dojo.query to get all the selected rows. But now we need to query scoped to a particular dom id. I made the fix and I believe it works. However I had an unrelated issue that caused me to delete and recreate my self hosting site, and due to bug 379041 I cannot save or start the site. So...please try the latest in one of your sites and report back. When I have a way to run a self hosting site I will continue.
(In reply to comment #2) > So...please try the latest in one of your sites and report back. When I have a > way to run a self hosting site I will continue. I tried to verify this in my self hosting site, but loading the git-status2 page gives an error on this line: > dojo.query("checkedRow", dojo.byId(this.explorer.myTree.id)) ^^^^^^^^^^^^^^^^^^^^ myTree is null It looks like the myTree variable isn't set until TableTree._init() returns, but init() indirectly calls ExplorerRenderer.getSelected() which contains the line above.
(In reply to comment #3) > It looks like the myTree variable isn't set until TableTree._init() returns, > but init() indirectly calls ExplorerRenderer.getSelected() which contains the > line above. thanks, Mark. Indeed, I must have been testing against an old site. I had some really weird git merge problems today and a merge conflict that i could NOT get rid of, so at some point I deleted my clone and started over. Problem is that I was testing against a site pointing to the old clone, and it was still working. So...I will try to fix this tomorrow. But this means there could be a problem in initial navigator state that I've now introduced in the build. I may need to run someone else's site to get a fix for that if we can't deploy tonight's build.
(In reply to comment #4) > (In reply to comment #3) > > > It looks like the myTree variable isn't set until TableTree._init() returns, > > but init() indirectly calls ExplorerRenderer.getSelected() which contains the > > line above. > > thanks, Mark. Indeed, I must have been testing against an old site. I had > some really weird git merge problems today and a merge conflict that i could > NOT get rid of, so at some point I deleted my clone and started over. Problem > is that I was testing against a site pointing to the old clone, and it was > still working. > > So...I will try to fix this tomorrow. But this means there could be a problem > in initial navigator state that I've now introduced in the build. I may need > to run someone else's site to get a fix for that if we can't deploy tonight's > build. Fixed in bug 377018 comment 25. I think the race is that getSelected function is called(in render.rowChanged function) during treeTable construction. At this moment explorer.myTree is not assinged till the treeTable construction finishes. There are several places in the explorer.js calling this function so we have to revisit them and maybe we need separate APIs. So I think my fix is still a hack. As I mentioned in the TODO, we may want a better approach. Here is the life cycle of a selection model: 1.Explorer loading 2.Restore previously selected model ids from cache 3.Mark selection in renderer by these ids 4.Collect selected model item from myTree. 5.Update selection service 6.Explorer load finishes 7.Build selection model from the model tree and selection service 8.From now the selection model controls navigation& selection and notify selection service. 9.When selection changes, we store the current selection by asking SELECTION MODEL. I think ideally in bullet 4 , we should ask the selection model but selection model is created in bullet 7. So the alternative is to ask the explore model to return an array of items by passing an array of ids. If we insist on calling dojo.query, we should make sure that getSelected fucntion is called after .myTree is initialized.
Libing is changing the way selections are stored. We shouldn't need to use dojo.query on the node classes anymore. He is almost ready to release this change, and once that happens, then this problem should be resolved.
this is working well now.
