Organization and Optimization - CommandExecutors

I've been looking to organize and optimize my plugins, part of this would include having a core command that either redirects or uses methods to slim down the space needed in each class and make things a little easier to look at. Basically, I was wondering if it would be possible to use the getCommand(String)#setExecutor to redirect commands to another class or if I'd have to just use an external method in another class. Either way, or if you have better ones, I'd be glad to hear your input. Thanks guys

 

travja
I'm not sure what you mean, but ofcourse you can use implement CommandExecutor in differenty classes, register the same way.
Annotation based commands handlers are really good for static commands.

 

travja

CommandExecutors are a great way of managing your plugin's commands, especially if you have more than one command. You could create a CommandExecutor like so:

Code:java

import org.apache.commons.lang.StringUtils;
import org.bukkit.Bukkit;
import org.bukkit.command.Command;
import org.bukkit.command.CommandExecutor;
import org.bukkit.command.CommandSender;
import org.bukkit.entity.Player;
 
import org.bukkit.plugin.Plugin;
 
public class TellCommandExecutor implements CommandExecutor{
    private Plugin plugin;
 
    public TellCommandExecutor(Plugin instance){
        plugin = instance;
    }
 
    @Override
    public boolean onCommand(CommandSender sender, Command cmd, String command, String[] args) {
 
        if (args.length < 1){
            handleBaseCommand(sender);
            return true;
        }
 
        handleTell(sender, args);
 
        return false;
    }
 
    private void handleBaseCommand(CommandSender sender){
        sender.sendMessage("You issued the command without any arguments.");
    }
 
    private void handleTell(CommandSender sender, String[] args){
        if (args.length < 1){
            sender.sendMessage("You have to write a message to send to the player.");
            return;
        }
 
        handleTell(sender, Bukkit.getPlayer(args[0]), StringUtils.join(args, " "));
    }
 
    private void handleTell(CommandSender sender, Player player, String message){
        sender.sendMessage(sender instanceof Player ? ((Player)sender).getName() : "Console" + ": " + message);
        player.sendMessage(sender instanceof Player ? ((Player)sender).getName() : "Console" + ": " + message);
    }
}

This is only a basic example of how I would use a CommandExecutor for a "/tell" command, which will whisper private messages to people. Don't forget to set the command's executor in your onEnable method:

Code:java

getCommand("tell").setExecutor(new TellCommandExecutor(this));

 

I'm sorry, I should have been more clear on what I was asking. For sub commands. If I were to use setExecutor in a command executor, redirecting to another for use of a sub command. Is that a good way to go or would it just be better to implement various methods for all my sub command stuff. /mycommand sub - /mycommand sub2 - etc.

 

travja

setExecutor will only work for commands that have been declared in your plugin.yml file. You could redirect your subCommands to a class designed to handle them however.

 

Dragonphase After running some tests, I have to redirect it, and then have the player run the command again by just building the command. But it appears to put the server into an infinite loop, causing the server to crash. I suppose I'll just have to do methods to handle everything.

 

travja use a CommandExecutor to get the subcommand, and let that delegate execution to another method/class

 

fireblast709 What exactly do you mean?

 

travja You only need a command executor for the top-level command so that Bukkit knows what to run when the command registered in the plugin.yml is passed. From there, you can check the arguments passed for the sub-commands.

How you structure your sub-commands is up to you, but you could have them implement CommandExecutor if you want to be able to switch them to top-level commands quickly. If you look here, you can see a good example of building your own sub-command structure.