Package com.ultikits.ultitools.abstracts.command.validation

Interface CommandValidator

All Known Implementing Classes:
CooldownValidator, PermissionValidator, SenderTypeValidator, UsageLockValidator
public interface CommandValidator
Interface for command validation following the Chain of Responsibility pattern. Validators are executed in order and can stop the chain by returning a failed result.
Since:
6.2.0
Version:
2.0.0
Author:
wisdomme

  • Method Details

    • validate

      CommandValidator.ValidationResult validate(CommandContext context)
      Validates the command context.
      Parameters:
      context - the command context to validate
      Returns:
      the validation result

    • getOrder

      default int getOrder()
      Gets the order of this validator. Lower values are executed first.
      Returns:
      the order value

    • shouldValidate

      default boolean shouldValidate(CommandContext context)
      Checks if this validator should be applied to the given context.

      An exception thrown here refuses the dispatch like one thrown from validate(CommandContext): the validators that already passed receive onRefused(CommandContext), and the exception propagates unchanged (as of 6.3.0).

      Parameters:
      context - the command context
      Returns:
      true if this validator should be applied

    • getName

      default String getName()
      Gets the name of this validator for debugging and logging purposes.
      Returns:
      the validator name

    • onComplete

      default void onComplete(CommandContext context, boolean commandSucceeded)
      Invoked once, after the mapped command method has returned or thrown, for each validator whose validate(CommandContext) succeeded during the chain run that gated this invocation. Never invoked for a validator that did not run -- skipped via shouldValidate(CommandContext), or never reached because an earlier validator in the chain failed. Validators are invoked in the same order the chain validated them, i.e. ascending getOrder().

      "In the chain that ran" and "receives this call" are the same fact by construction: the caller drives this hook from ValidatorChain.ChainValidationResult#getPassedValidators(), never from a hard-coded reference to a specific validator instance.

      The default implementation is a no-op, so existing validators that only gate -- and have no side effect to apply afterward -- require no change.

      Parameters:
      context - the command context
      commandSucceeded - true if the mapped method returned without throwing, false if it threw
      Since:
      6.3.0

    • onRefused

      default void onRefused(CommandContext context)
      Invoked once, instead of onComplete(CommandContext, boolean), for each validator whose validate(CommandContext) succeeded when the dispatch is then refused before the mapped method runs: by a validator later in the chain, by an exception from a later validator's shouldValidate(CommandContext) or validate(CommandContext), by the argument-count check, or because a parameter could not be parsed. Validators are invoked in chain order. Never invoked for a validator that did not run or that refused.

      A validator that acquires something in validate -- UsageLockValidator takes its lock there -- releases it here; the mapped method never ran, so effects that belong to an invocation (a cooldown) are not applied. Before 6.3.0 these refusals released nothing, and a @UsageLimit lock stayed held until the player quit (#568).

      The default implementation is a no-op, like onComplete's.

      Parameters:
      context - the command context
      Since:
      6.3.0