...
A command usually needs to validate it's options. There are three options ways to do validations. One is provided by the CliOption itselfto mark an option as mandatory, one is to use Converters, and the other one is to use Interceptors. These are all done in the Gfsh client vm. So itIt's best to do validation in these places other than putting the validation logic inside the command execution which is executed on the locator.
...
| Code Block | ||
|---|---|---|
| ||
@CliOption(key = "name", mandatory = true) String regionregio |
Converters
Converters are the way for you to manipulate value input before you feed it into your command class. You can use them to convert and validate , convert user input and provide hints for auto-completion. Gfsh provides commonly used converters that would convert strings to boolean, int, long, String[] (comma separated), enum, Date, File etc. These converters also serves validation purposes when converting the values. For example, below is an option specified in "test "command. If a command is "test --count=abc", then this command will fail the parser validation, because the parser can not convert "abc" into an integer.
| Code Block | ||
|---|---|---|
| ||
@CliOption(key = "count") int count |
A major usage of converters is auto completion, but the converter can also be used to validate, e.g if the filename Converters is a way to provide commonly-used validation that can be shared across multiple commands. E.g. a file type converter can validate if the filename is in the correct format , or if it exists in the local file system, or if the class name specified is in the correct format. and then converts it to File type. If we have such converters handy, all commands that needs a file option can use it and get the benefit of free validation. If you find yourself trying to validate a common type, consider using a converter.
Usually you can tell the parser to use a converter by just specifying your parameter type. If there is only one converter available for that type, then the parser will use that to convert your value, but if there are multiple converters available, then it's indeterministic as to which one parser will use. To bypass this ambiguity, you will need to use optionContext in @CliOption to narrow down which converter to use. e.g. below option specified an optionContext string:
...