Updates help generation for literal arguments #537
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For #536 Now displays the literal value instead of the node name
JorelAli
requested changes
Apr 3, 2024
Member
JorelAli
left a comment
There was a problem hiding this comment.
Looks good - just a few minor changes please.
commandapi-core/src/main/java/dev/jorel/commandapi/CommandAPIHandler.java
Outdated
Show resolved
Hide resolved
commandapi-core/src/main/java/dev/jorel/commandapi/arguments/AbstractArgument.java
Outdated
Show resolved
Hide resolved
JorelAli
approved these changes
Apr 3, 2024
willkroboth
added a commit
that referenced
this pull request
Apr 29, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Apr 29, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Apr 30, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
May 13, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
May 14, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Jun 3, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Jun 8, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Jun 17, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Jul 4, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Aug 15, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Sep 1, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Oct 26, 2024
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Feb 2, 2025
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Feb 2, 2025
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Feb 15, 2025
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
willkroboth
added a commit
that referenced
this pull request
Mar 7, 2025
- Reordered constructor arguments to more closely match the order in `ExecutableCommand`
- This branch is now definitely backward incompatible (though not majorly)
- Replaced `List<String> argsAsStr` with `Node rootNode`
- Added `RegisteredCommand.Node` class
- Has an `argsAsStr` method as a replacement for the parameter of `RegisteredCommand`
- Simplified representation of the Brigadier's `CommandNode` structure for the command
- Removed `AbstractArgument#getHelpString` and `RegisteredCommand#arguments` (Added by #537)
- The `RegisteredCommand.Node` structure is used to generate usage
- `Literal` and `MultiLiteral` have separate logic for creating thier `RegisteredCommand.Node, wherein they define a different help string
- TODO: #537 didn't have any tests, so I'm only guessing this new implementation works the same. In general, add more tests for usage generation.
- Removed `ExecutableCommand#getArgumentsAsStrings` and `AbstractArgument#appendToCommandPaths`
- Added `AbstractArgument.NodeInformation` to help pass around enough information to generate Brigadier nodes and `RegisteredCommand.Node`s in one `AbstractArgument` tree traversal.
- Modified the signatures of a few methods to facilitate this, including overriding methods
- TODO: This broke `Previewable` arguments, so I'll have to tweak those
- Changed `CommandAPIHandler#registeredCommands` from an `ArrayList` to a `LinkedHashMap`
- Instead of creating one `RegisteredCommand` object for each command path, `RegisteredCommand`s are merged when they share thier command name and namespace
- One call to `ExecutableCommand#register` creates one `RegisteredCommand` object (if it has a namespace, an unnamespaced copy is created too)
- `CommandAPIPlatform#postCommandRegistration` was reverted to original signature
- NOTE: `CommandAPI#getRegisteredCommands` still returns a `List<RegisteredCommand>`
- Updated `CommandAPICommandRegisteredCommandTests` and `CommandTreeRegisteredCommandTests`
- Added `RegisteredCommandTestBase` to handle common utility methods
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For #536
Now displays the literal value instead of the node name