Craig Oates
4 years ago
1 changed files with 42 additions and 42 deletions
@ -1,42 +1,42 @@
|
||||
If you are unsure what a command-method is, please read the following page: |
||||
|
||||
- [Overview of Command-Methods](Overview-of-Command-Methods) |
||||
|
||||
When it comes to writing command-methods, there are certain requirements you must meet. They are: |
||||
|
||||
1. Command-methods must be `static`. |
||||
2. Every command-method must return a `string`. |
||||
3. The `ConsoleCommands` class must be `public` and `static`. |
||||
4. Every command-method-method must reside in the `ConsoleCommands` class. |
||||
|
||||
The reason why every command-method must return a `string` is because Console.Waterworks (C.W.) needs to provide feedback to the end-user. With that said, you are free to write to the console whenever you want. On top of that, you can return an empty `string` if you want. C.W. does not care what is in the `string` as long as it is a `string`. |
||||
|
||||
Having taken the above into account here is what a typical command-method looks like, |
||||
|
||||
```c# |
||||
public static string CommandMethodName() |
||||
{ |
||||
// Your code goes here... |
||||
return "The result/message you want to feedback to the end-user." |
||||
} |
||||
``` |
||||
|
||||
More examples can be found at the following links: |
||||
|
||||
- [CW-Console's ConsoleCommands.cs](https://git.abbether.net/craig.oates/Console.Waterworks/blob/master/Console.Waterworks/CW-Console/ConsoleCommands.cs) |
||||
|
||||
What is important to note here is the importance of the command-method names. The names you use are the exact same commands your end-user will enter at run-time. The console's input is, also, case-sensitive. This means you can have two command-methods called `Test` and `test` and have them do different things. |
||||
|
||||
![screenshot of command-method and console commands](method-mapping.gif) |
||||
|
||||
Another feature of C.W. is it parses and coerces input arguments. This means your command-methods can include arguments and C.W. takes care of the error-handling and messaging for you. |
||||
|
||||
![screenshot of error-handling 1](invalid-command-input.gif) |
||||
|
||||
![screenshot of error-handling 2](invalid-arguments-input.gif) |
||||
|
||||
To be clear, there are limits to the amount of types you can use with your command-methods. For a full, list of all the coercion types, please refer to the Coercion Types List in the "As Source Code" section. The link for it is as follows: |
||||
|
||||
- [Coercion Types List](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Coercion-Types-List) |
||||
|
||||
If you write command-methods with arguments **not** on the coercion list, you will get a run-time error. With that said, you are free to use whatever types you want **inside** the command-methods. |
||||
If you are unsure what a command-method is, please read the following page: |
||||
|
||||
- [Overview of Command-Methods](Overview-of-Command-Methods) |
||||
|
||||
When it comes to writing command-methods, there are certain requirements you must meet. They are: |
||||
|
||||
1. Command-methods must be `static`. |
||||
2. Every command-method must return a `string`. |
||||
3. The `ConsoleCommands` class must be `public` and `static`. |
||||
4. Every command-method-method must reside in the `ConsoleCommands` class. |
||||
|
||||
The reason why every command-method must return a `string` is because Console.Waterworks (C.W.) needs to provide feedback to the end-user. With that said, you are free to write to the console whenever you want. On top of that, you can return an empty `string` if you want. C.W. does not care what is in the `string` as long as it is a `string`. |
||||
|
||||
Having taken the above into account here is what a typical command-method looks like, |
||||
|
||||
```c# |
||||
public static string CommandMethodName() |
||||
{ |
||||
// Your code goes here... |
||||
return "The result/message you want to feedback to the end-user." |
||||
} |
||||
``` |
||||
|
||||
More examples can be found at the following links: |
||||
|
||||
- [CW_Console's ConsoleCommands.cs](https://git.abbether.net/craig.oates/Console.Waterworks/src/branch/master/Console.Waterworks/CW_Console/ConsoleCommands.cs) |
||||
|
||||
What is important to note here is the importance of the command-method names. The names you use are the exact same commands your end-user will enter at run-time. The console's input is, also, case-sensitive. This means you can have two command-methods called `Test` and `test` and have them do different things. |
||||
|
||||
![screenshot of command-method and console commands](method-mapping.gif) |
||||
|
||||
Another feature of C.W. is it parses and coerces input arguments. This means your command-methods can include arguments and C.W. takes care of the error-handling and messaging for you. |
||||
|
||||
![screenshot of error-handling 1](invalid-command-input.gif) |
||||
|
||||
![screenshot of error-handling 2](invalid-arguments-input.gif) |
||||
|
||||
To be clear, there are limits to the amount of types you can use with your command-methods. For a full, list of all the coercion types, please refer to the Coercion Types List in the "As Source Code" section. The link for it is as follows: |
||||
|
||||
- [Coercion Types List](https://git.abbether.net/craig.oates/Console.Waterworks/wiki/Coercion-Types-List) |
||||
|
||||
If you write command-methods with arguments **not** on the coercion list, you will get a run-time error. With that said, you are free to use whatever types you want **inside** the command-methods. |
||||
|
Loading…
Reference in new issue