Forums » Community Projects
Plugin authors: Consider using RegisterUserCommand only once
As a plugin user (soon-to-be author) I have noticed a tendency of a few plugins to have more than one command. This is logical when a plugin provides more than one feature and there is Nothing Wrong With Features. This can nevertheless lead to command saturation and conflicts.
I propose that authors attempt to limit their usage of RegisterUserCommand only once per plugin. The command you register would be the plugin's name. Further plugin-specific commands could be routed through the plugin's command.
I've posted up an example of this on http://vo-wiki.com/racecar/index.php?title=API_RegisterUserCommand
Feel free to use the code in the above page if you think this is a good idea. If you aren't convinced this is a good idea, I'd like to hear your thoughts.
There's more that can be done with this, I'm sure. One thing would be to print the available sub-commands within the primary command. A simple for-pairs loop over the commands table would probably work nicely.
I propose that authors attempt to limit their usage of RegisterUserCommand only once per plugin. The command you register would be the plugin's name. Further plugin-specific commands could be routed through the plugin's command.
I've posted up an example of this on http://vo-wiki.com/racecar/index.php?title=API_RegisterUserCommand
Feel free to use the code in the above page if you think this is a good idea. If you aren't convinced this is a good idea, I'd like to hear your thoughts.
There's more that can be done with this, I'm sure. One thing would be to print the available sub-commands within the primary command. A simple for-pairs loop over the commands table would probably work nicely.
Might want to rewrite that function on the wiki.
I don't think many plugins really use more then one command.
Personally i tend to just use one, sometimes second one that's a two letter shortcut.
Tho remember that you can't directly bind command with arguments so if you are making bindable functions you pretty much want to make each one a separate command.
Personally i tend to just use one, sometimes second one that's a two letter shortcut.
Tho remember that you can't directly bind command with arguments so if you are making bindable functions you pretty much want to make each one a separate command.
@blacknet: I'll be happy to do so... but what is wrong?
@maq:
Most plugins don't... you're right. I really had meant to point that out... (fixed... lol)
It is good if you are using the register basically once, maybe twice. Essentially that's what I'm suggesting anyhow. Although I would probably leave the abbreviated form up to the user via an alias.
!^#$... I totally forgot about that. Hmm. Maybe it's not all for naught. Aliases can handle that no problem and the user doesn't need to dig into the lua code to resolve any command conflicts. That's good right?
It is easier for to edit the alias than it is to edit the lua code (and to keep editing when the code is updated). They may choose a name like /myplugin_start as an alias for "/myplugin start"
I don't know. Am I totally off course here?
@maq:
Most plugins don't... you're right. I really had meant to point that out... (fixed... lol)
It is good if you are using the register basically once, maybe twice. Essentially that's what I'm suggesting anyhow. Although I would probably leave the abbreviated form up to the user via an alias.
!^#$... I totally forgot about that. Hmm. Maybe it's not all for naught. Aliases can handle that no problem and the user doesn't need to dig into the lua code to resolve any command conflicts. That's good right?
It is easier for to edit the alias than it is to edit the lua code (and to keep editing when the code is updated). They may choose a name like /myplugin_start as an alias for "/myplugin start"
I don't know. Am I totally off course here?
Well, generally it'll be something like /pluginname_command yea, makes sense anyway,
as for having users make aliases, they can of course if they know such command exist... which some don't, also it's additional setup work.
You might as well provide easier to use option.
Beside all that, i find that if you have more then a few settings CLI quickly gets unwieldy and you might as well go for a GUI.
Tho maybe having standardized way to make it (like you are trying to do) would help, but i never got around to that.
Anyhow, i don't really see this being a big issue.
as for having users make aliases, they can of course if they know such command exist... which some don't, also it's additional setup work.
You might as well provide easier to use option.
Beside all that, i find that if you have more then a few settings CLI quickly gets unwieldy and you might as well go for a GUI.
Tho maybe having standardized way to make it (like you are trying to do) would help, but i never got around to that.
Anyhow, i don't really see this being a big issue.
No, definitely not a big issue, fortunately. Discussion like this can only better the situation of course.
I'm quite happy with using the CLI. Perhaps that is because I have a natural inclination towards it being a *nix user. Of course not everyone is so inclined. I think the CLI can end up being significantly more powerful, and maintainable than a GUI. End users will probably almost always prefer the guification.
I'm quite happy with using the CLI. Perhaps that is because I have a natural inclination towards it being a *nix user. Of course not everyone is so inclined. I think the CLI can end up being significantly more powerful, and maintainable than a GUI. End users will probably almost always prefer the guification.