Community
Participate
Working Groups
we put the command that was invoked in the calldata (CommandInvocation) for a command. So theoretically one could just grab the command and get the parameters, etc. but it might be nicer to include fields in the data structure for some of these (for example, we fill in id rather than forcing clients to use command.id). Need to reconcile when/why a client should grab info from the command that was invoked vs. having it in the data structure.
In commit 387d014684e3f7dd9b421ebe0a1418d0855b348a I have made the command service consistent about what it does here. The parameters and id are provided in the CommandInvocation (calldata). This is really just a nod to the fact that these used to be parameters in the callback, and I don't want callbacks to have to reach into the command where they were previously just using a parameter. BUT...we still need to reconcile the use of the parameters object, and whether it is indeed the same object as that provided to the command, or a copy of it. Currently we use the same object, but we have to be careful, because objects from different scopes could unintentionally receive a parameter value from an invocation against a different scope. The case I'm seeing right now is that "new folder" in an item menu is getting parameter values from a previous invocation of "new folder" in the toolbar. As long as this is just a default (and the prompt still occurs) this is probably OK.
(In reply to comment #1) > BUT...we still need to reconcile the use of the parameters object, and whether > it is indeed the same object as that provided to the command, or a copy of it. > Currently we use the same object, but we have to be careful, because objects > from different scopes could unintentionally receive a parameter value from an > invocation against a different scope. This turned out to be the WRONG THING to do in some cases. For example, consider using a slideout to collect a password. If the parameters object from the original command is used, then the password would be the default value for invocations of the command against different items (such as different repos in a git clones list). I've changed the framework and clients so that: - a command invocation copies the parameter list so that values are never reset in the original command parameter object. - the parameter collector and all callbacks use commandInvocation.parameters and not commandInvocation.command.parameters - this is documented in CommandInvocation > The case I'm seeing right now is that > "new folder" in an item menu is getting parameter values from a previous > invocation of "new folder" in the toolbar. As long as this is just a default > (and the prompt still occurs) this is probably OK. This is now fixed. If you use "new folder" in the toolbar, it will remember the last value for the most part (unless you navigate around in the tree, etc.). If you use "new folder" in the menus, the previous value is remembered per row (invocation) but you don't use the defaults across rows. This actually feels right to me. Likewise...in git clones. If you use More->Push on a branch, the default credentials are remembered per repository in the item menu, but not across repositories. The toolbar items never remember credentials because the git code is always rerendering the commands which resets the defaults. Fixed in 8723d4dc04a44c0d001711267c578bc554aebb24
