Extend the GUI: Guide for future Developers

Structure

The GUI is implementing the MVC-Pattern:

• Model = CLIModelInterface
• View = CLIInterface
• Controller = CLIControllerInterface

Adding a new Command

If you want to add a new command to the CLI, do the following steps:

1. Create a new class for your command and let it inherit the abstract class CLICommand.
2. Add it to the CLIController
3. Define the argument structure
4. Implement the logic

1. Create a new command class

Add a new class to the utils.cli.controller.command package. Please name the class according to the naming scheme: "CLIC + WhatTheCommandDoes" and let it extend the CLICommand class.

public class CLICDoSomething extends CLICommand {

@Override
public void execute() throws Exception {
    ui.printInfo("Yay, my command works :)");
}
...

Some errors should occur. Add the missing constructor and methods. You can leave them like your IDE auto-creates them for now. If you want you can print something to the UI in the execute() method, to see some output when we call it. We come to the real implementation of your command in a moment.

2. Add the command to the CLIController

Of course nothing happens yet, as no instance is created and gave to someone who handles it. This is the next step. The handler of all the commands is the CLIController, which will call a command depending on the user input.

Navigate to the CLIMain class and add your command to the CLIController.

public class CLIMain {

    public static void main(String[] args) throws SharkException {
        CLIModelInterface model = new CLIModel();

        CLIControllerInterface controller = new CLIController(model);
        
        controller.addCommand(new CLICDoSomething("doSomething", true));

        controller.addCommand(new CLICSaveLog("saveLog", false));
        controller.addCommand(new CLICShowLog("showLog", false));
        controller.addCommand(new CLICExit("exit", false));
        ...

The constructor inherited from the CLICommand class requires two parameters.

The first one is the command identifier. This string is what the user needs to enter to start your command.

The second parameter is from type boolean and requires a short moment of thinking to set it right. As described in GUI Usage wiki entry, the history of all commands entered by the user are recorded, so that they can be saved to a file and used for running specific test over and over again. Actually, not all commands are saved and your command might not need to be saved as well, but that's fairly unlikely. Remember, that this CLI has the main purpose of setting up test environments and any command can be the cause for an error to occur. So if the command isn't saved to the history, errors might occur when its called manually but not when the CLI is started with a redirected input stream, as the command isn't invoked then. Have a look at the existing commands and if they are remembered or not to get a better feel for setting this flag right.

You could run the CLI now and your command should appear in the command list and if you enter the command identifier, the command should be found and executed. If you implemented the line which prints out a little string to the console, you should see this string now.

3. Define the argument structure

Some commands need additional user input. Think of the command that creates a new channel. The URI and the name of the channel are definitely two things, the user needs to input. Have a look at the example below:

Run a command by entering its name from the list above: mkCh
> mkCh
Please input the channel uri: test/uri
> test/uri
Please set the channel name: TestChannel1
> TestChannel1
Should this channel be created, if a channel with the same uri already exists? false
> false

The CLI is build, so that the command identifier is first entered by the user and afterwards all arguments are prompted to the user to fill them out. In the example, a new channel is created with the "mkCh" (make channel) command. Three arguments are needed which the user fills out one by one in the order they were specified. The questions can be defined as well as the type of input you expect.

Questionnaires, Questions and Arguments

Three objects are used for this type of user input:

• CLICQuestionnaire
• CLICQuestion
• CLICArgument

A Questionnaire object can hold multiple questions and is, what the CLI object receives and processes.

Every Question object has a string attribute representing the question that should be asked and an Argument object in which the answer of the user is stored.

The Argument object has specific type of object which can be stored in it. Also, it includes a method to parse the user input to the object.

The CLI lets the user fill out every question from the questionnaire. If a user input can't be parsed, the user is asked again for a valid input.

Predefined Arguments The CLICArgument class is abstract and you would need to write your own class to handle user input. As some types of input are frequently needed, there are some predefined subclasses:

• CLICStringArgumet - returning a string object
• CLICIntegerArgument - returning an int
• CLICBooleanArgument - returning a boolean
• CLICKnownPeerArgument - returning a PeerValues object
• CLICChannelObject - returning a SharkMessengerChannel object

See the documentation for more details on these classes. If you need other types (e.g. Double) jump to ...

Defining the CLICQuestionnaire object

In your command class, add