Skip to content

Commit

Permalink
Up to date
Browse files Browse the repository at this point in the history
  • Loading branch information
Mqzn committed Dec 13, 2024
1 parent ca165c3 commit 4aa6476
Show file tree
Hide file tree
Showing 3 changed files with 24 additions and 9 deletions.
2 changes: 1 addition & 1 deletion docs/Imperat/Command Help.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ public final class GroupCommand {
) {
source.reply("Group entered= " + group.name());
//showing help to the user
help.display();
help.display(source);
}
}
```
Expand Down
12 changes: 8 additions & 4 deletions docs/Imperat/Dispatcher API.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ It's a flexible abstract class in Imperat, which parses the annotated command cl
it's used internally inside the method `Imperat#registerCommand(T instance)`.
Simply, It defines how the data from the annotations (inside your Command class) are translated and converted into command objects.

You can customize and make your own AnnotationParser as you wish by using `Imperat#setAnnotationParser(AnnotationParser<C>)` where C is automatically
You can customize and make your own AnnotationParser as you wish by using `YourPlatformImperatConfigBuilder#setAnnotationParser(AnnotationParser<C>)` where C is automatically
your command-sender type

Refer to the java docs if you need more details on how to implement your own `AnnotationParser`, although I would never recommend you to do this, as the default `AnnotationParser` is competent enough.
Expand All @@ -44,7 +44,7 @@ it's own way of identifying whether the command-sender/source has a permission o
### Implementing your own Permission Resolver

If you ever wanted to make your own `Permission Resolver` you should consider
adding it as a parameter inside the `YourCommandPlatform.create()`, Refer to the java docs
adding it as a parameter inside the `YourPlatformImperatConfigBuilder#permissionResolver()`, Refer to the java docs
for more info about method parameters for creation of Imperat instances from various supported platforms and you may would like to check [Supported-Platforms](Supported-Platforms.md)

*Quick **Bukkit** example:*
Expand All @@ -65,7 +65,7 @@ class MyPlugin extends JavaPlugin {
@Override
public void onEnable() {
//now you injected the your own instance of permission resolver into the Command Dispatcher
imperat = BukkitImperat.create(plugin, new MyBukkitPermissionResolver());
imperat = BukkitImperat.builder(this).permissionResolver(new MyBukkitPermissionResolver()).build();
}
}
```
Expand Down Expand Up @@ -141,11 +141,15 @@ The `areAmbigious(CommandUsage, CommandUsage)` method checks if any two usages o
#### Common Scenarios
Here are some important common scenarios that will help you better understand
how Imperat recognizes and when does it tolerate an ambiguity.

##### Scenario #1
if you have the command `group` and it has 2 usages which are `/group <group>` and `/group help` , an actual group can be called **'help'**. Luckily however, Imperat prioritizes subcommands compared to value arguments, so the dispatcher will tolerate this pseudo-ambiguity. <br/>

##### Scenario #2
If you have the command `buy` with 2 usages which are `/buy <itemId>` and `/buy <itemName>`
Even if both parameters `itemId` and `itemName` are of different types, the current `Imperat` cannot tolerate this ambiguity coming from these 2 usages.
Even if both parameters `itemId` and `itemName` are of different types (Integer vs String), the current `Imperat` can work with this depending
on the `UsageVerifier`, the default usage verifier would deal with such ambiguity. However it may cause some unknown problems.


:::warning
We don't recommend implementing your own UsageVerifier, unless you know what you're doing, since the `DefaultUsageVerifier` is competent enough.
Expand Down
19 changes: 15 additions & 4 deletions docs/Imperat/Introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,20 +17,31 @@ These objects are registered/injected into the class `Imperat` which handles all
**Answer:** It's the Ultimate class handling all data needed when processing and registering
commands objects (`Command`).
You have to create **new instance** of the imperat.
on the **start** of your platform by calling `YourPlatformImperat#create` (the method is static) to create
and initialize a new instance of `Imperat` type.
on the **start** of your platform by calling `YourPlatformImperat#builder` (the method is static) to configure your imperat instance,
then finally end the chain with `build` method to return a new instance of `YourPlatformImperat` type.

:::tip[TIP]
Creation of an instance of your `PlatformImperat` depends mainly on which platform
you are using. For more details, Check out [Supported-Platforms](Supported-Platforms.md)

But despite having various types of imperat implementations for different platforms,
all of them are **configurable/customizable**
:::

# Customizing Imperat



If you wanted to register a [Context Resolver](Context%20Resolver.md) or a [Parameter Type](Parameter-Type.md) , or even
set a [Suggestion Resolver](Suggestion%20Resolver.md) for tab-completion in commands, You would have to
call some methods using your platform's dispatcher instance/
call some methods while configuring imperat.

*Quick-example:*
```java
BukkitImperat imperat = BukkitImperat.builder(plugin)
// do stuff here
.build();
```

For a complete detailed guide on this, please check out [Dispatcher API](Dispatcher%20API.md)

:::note
Expand Down

0 comments on commit 4aa6476

Please sign in to comment.