-
Notifications
You must be signed in to change notification settings - Fork 3
Modules
Modules are kordx.commands
' way of grouping commands into logical groups. In its most basic sense, a Module
is a named container for commands.
kordx.commands
Won't allow you to create Modules
directly, instead you can use the module
DSL to create a ModuleModifier
.
val helpModule: ModuleModifier = module("help", MyContext) {
command("help") {
invoke {
//...
}
}
command("modules") {
invoke(WordArgument.named("module").optional()) {
//...
}
}
}
ModuleModifiers
apply themselves to a module with a given name, kordx.commands
will automatically create new modules when a ModuleModifier
asks for a non-existent one. This allows you to change modules after declaration.
Assume the help module defined above is comming from an imported library. It's great and all, but we want to add another command, we can just extend the help module:
val helpModuleExtension: ModuleModifier = module("help", MyContext) {
command("commands") {
invoke(WordArgument.named("command").optional()) {
//...
}
}
}
The processor will apply both ModuleModifiers
to the same module named "help", effectively allowing us to extend a predefined module.
This same technique can also be used to split up big modules across several files if you find it to improve readability.
Try not to use this to modify already existing commands, the order in wich multiple modifiers are ran is not guaranteed, only that they all will eventually be ran.
Modules
also come with their own MetaData
if you have any processors that need to work on a module level. An example of this is the EachCommandModifier
, which will apply a given lambda to every command in the module.
any property or function returning a ModuleModifier
will be picked up by the annotation processor if it is annotated with @Autowired
or in a file annotated with @file:Autowired
@file:Autowired //alternatively
@AutoWired
suspend fun myModule(dependency: MyDepedency) = module("my-module", MyContext) {
//...
}