boscojared / disparse Goto Github PK
View Code? Open in Web Editor NEWAn ergonomic, simple, and easy-to-use command parsing and dispatching library for Discord bots
License: MIT License
An ergonomic, simple, and easy-to-use command parsing and dispatching library for Discord bots
License: MIT License
If there is no long flag present, disparse should not fail. Only a short-flag should be required to use flags. Might be a bug
test the body out
It would be nice if --number=5
or -n=5
also worked along with --number 5
and -n 5
This involves work in all of the modules of disparse, namely:
The goal of this feature is to abstract sending a direct message to a user. In disparse-core, there should be a method added to AbstractDispatcher which is an abstract method left to be implemented by each of jda, d4j, and smalld.
Then in each Dispatcher class for each module, there will be an implementation specific to the underlying library. Also, don't forget about the Dispatcher that is in disparse-core/src/test/java/disparse/discord/TestDispatcher.java
This feature can be tested manually for now using the disparse-testing
module.
This issue proposes to add an optional step in the Dispatch.Builder to auto generate a commands.md
file in the root directory.
The default for this option should be false.
The file structure should look like this
Template:
# Commands
## Command Name
Command Description
* **Cooldown:** Command cooldown
* **Required Permission:** Permissions if specified
* **Required Role:** Role if specified
#### Arguments
* `shortname`, `longname` : argument description
#### Usage
`example usage from usage annotation`
Example:
# Commands
## mute
This command will mute the target user
* **Cooldown:** 5 seconds per User
* **Required Permission:** Ban
* **Required Role:** Moderator
#### Arguments
* `-u`, `--user` : The target userid to mute
#### Usage
`!mute -u 0123456789`
If any information is not provided (permissions, roles, cooldown, they can be marked as N/A
)
Feature Description: Currently, there is a line in each Dispatcher implementation that looks similar to this. This line explicitly checks if the incoming author is a Bot, and stops processing a command.
While this is a sane default, it could perhaps be desirable to be able to accept bot commands. This should be added in some way to the AbstractDispatcher which will put us in a position to provide a default implementation of the dispatch.
Usage:
Dispatcher dispatcher = new Dispatcher.Builder()
.allowIncomingBotMessages(true)
.build();
The default will be false
.
Modules Affected: All modules are affected. core
, d4j
, jda
, and smalld
will need to be changed. Therefore, the module in the commit message must be [core]
or [core/dispatch]
.
Out Of Scope:
Moving the entire dispatching logic to the AbstractDispatcher. This will eventually be done; However, it is out of scope for this issue. Keep it simple.
Making the boolean on a per-guild basis. This will also eventually be done, but is out of scope. This issue is only dealing with the configuration globally for the bot.
Requirements Checklist:
As always, be sure to read the contributing guidelines in the root of the project to understand the commit message template and other considerations.
This feature / task write-up is in response to the original issue posted here.
Feature Description: Currently, @Flag
types can be put over the following types of fields: Integer
, Boolean
, List
, and String
. In the case of Integer
and Boolean
, only the wrapper types are supported. Disparse should be extending to be able to set the values of fields that are of type int
or boolean
. After this feature, the total fields supported by @Flag
will be Integer
, int
, Boolean
, boolean
, List
, and String
.
Reproduce:
PrimitiveCommand.java
public class PrimitiveCommand {
@ParsedEntity
static class PrimitiveOpt {
@Flag(shortName = 'n', longName = "number")
int number = 0;
}
@ParsedEntity
static class WrapperOpt {
@Flag(shortName = 'n', longName = "number")
Integer number = 0;
}
@CommandHandler(commandName = "test")
public static DiscordResponse test(WrapperOpt option) {
return DiscordResponse.of("You chose number: " + option.number);
}
}
Copy paste the above code into the class, resolving the imports as needed. When PrimitiveCommand::test
accepts WrapperOpt
the command will work because it is using the wrapper Integer
type. When PrimitiveCommand::test
is switched to use PrimitiveOpt
the command will throw a stacktrace due to not yet supporting the int
primitive type in Disparse.
Modules Affected: This is a core issue only, and therefore changes should only need to be made into disparse-core
. The commit message should following the contributing guidelines and be something like: [core] support primitive types as flag fields
.
Where to look: Utils.java has a few conditions explicitly type checking the field and setting to an enum. This would need to be updated first.
CommandRegistrar.java is where the command will eventually be dispatched with the correctly set values. This may or may not need to change after Utils.java is changed to accept both Integers and ints.
Tests: Ideally a PR would include a few tests in DispatchIntegrationTests.java but ultimately it is not required.
As always, read the contributing guidelines and/or reach out on Discord @bosco#8564 for help or discussion.
some text to show it works
Middleware could potentially change the permissions of commands by returning false in certain conditions, especially if the use-case is more complex than supported by Disparse. The help command runs without considering anything about middleware's return value and therefore you could show a command to a user through the help command they are unable to run. This is poor UX and can confuse the user.
We can filter the command collection to only hold commands that would pass through the middleware for the current invocation. This can be done by modifying the AbstractDispatcher's help method here to run through the middleware chain and filter out any commands that return any false's.
To claim the issue and get a little more support, feel free to ping on Discord @Bosco#8564
or join the Discord for Disparse's development here.
Currently sendCooldownMessage
accepts a boolean type. See docs
This feature request proposes creating an Enum to extend functionality.
disabled
- cooldown message is not sent
reaction
- invocation command receives a reaction with "๐" indicating the command is on cooldown.
enabled
- cooldown message is sent.
Currently checking of the sendCooldownMessage
field is done here
Problem
Assume a command named foo
accepts a repeatable flag with the following definition:
@Flag(shortName = 'r', longName = "repeatable")
List<String> repeats = new ArrayList<>();
This means we are able to invoke this command like: !foo -r "first" -r "second" -r "third"
Our repeats
field will now show ["first", "second", "third"]
which is good and expected.
If we mix-and-match the longName with the shortName; However, we see that the order we receive is unexpected and surprising: !foo -r "first" --repeatable "second" -r "third"
now shows that our repeats
field is ["second", "first", "third"]
Mix-and-matching repeatable flags by shortName and longName should be supported.
Where To Look
In the disparse.parser.Parser there is a parse
method that handles parsing out short flags, and long flags, and then finally merges them into one map using Map#merge which does not respect the initial order of the flags in the original args.
Parser should be the only file needing to be changed for this issue.
Testing
There already exists a test in the integration tests here that documents the incorrect behavior. This test will fail when the parser correctly handles this case, and this test should change the order of the list elements to make it pass ( thus proving that the change was successful ).
The commit name should be prefixed with [core/parser]
and as always, be sure to read the contributing guidelines in the root of the project to understand the commit message template and other considerations.
Super cool issue body
Currently a @Flag
will work on an Integer field, but not with an int field. The exception thrown indicates it's trying to set an int field to a boolean
some text to show it works
It's useful to have longer help descriptions for commands. It's useful to have short descriptions as a summary of commands.
Tools such as Javadoc and click allow long descriptions and use the first sentence as the short description.
On the help page for the full bot, use the first sentence of the description as a summary
On the help page for a specific command, use the full description (this also means it's probably better off not in the title of the embed, but just as plain text)
Also possible is supporting summary
in the @CommandHandler, so that it can be explicitly given if preferred, but defaulting to the first sentence of description
if it's not given.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.