Configurer les paramètres d'une action

[seballot]

Avant de continuer à refactorer toutes les actions vers la nouvelle syntaxe en classe, je pense qu'il y quelque chose à faire sur la déclaration des paramètres (i.e. arguments) de l'action

Jérémie et Adrien avait déjà cerné le problème et ont mis en place une fonction formatArguments

Je pense qu'on peut aller plus loin et faire quelque chose de plus générique et DRY

Proposition

S'inspirer de la syntaxe symfony pour déclarer les argument des commandes symfony

Exemple pour l'action Button

class ButtonAction extends YesWikiAction
{
  public function configure()
  {
      $this
          ->addArgument("link", UrlArgument, ["required" => true])
          ->addArgument("text", TextArgument, ["required" => true])
          ->addArgument("hideifnoaccess", BooleanArgument, ["default" => true]);
  }
  
  // ...
}

Et on peut déclarer les types d'argument avec quelque chose comme

class Argument
{
    public function format($arg)
    {
        return $arg;
    }
}

class TextArgument extends Argument {}
class UrlArgument extends TextArgument {}

class BooleanArgument
{
    public function format($arg)
    {
        return in_array($arg, ["true", "1"]);
    }
}

Traitement automatisés

Avec cela on pourra automatiquement détecter et mettre une alerte sur les argument obligatoire non rempli, assigner les valeurs par default, et faire le formattage/parsing des arguments un peu spéciaux genre groups ou displayfields en créant un nouveau type d'argument

Inherit from another action

L'avantage avec la function configure c'est qu'on peut faire des trucs genre

class CustomButtonAction extends ButtonAction
{
  function configure()
  {
     parent::configure();
     $this
       ->removeArgument('text');
       ->updateArgument("link", UrlArgument, ["required" => false]);
       ->addArgument("newarg", TextArgument);
  }
}

Documentation automatisée

L'autre avantage c'est qu'on peut récupérer les infos déclarées dans configure pour les utiliser dans l'action builder.
C'est notament important pour les valeur par default, car si dans la doc yaml on met que la valeur par défault d'un argument est "true" et que dans l'action php l'argument est par défault initialisé à "false", ça fait un peu tout foirer

Mais je pense qu'on va quand meme garder les fichier yaml car il y aura toujours des config qui trouveront difficilement leur place dans le configure notamment la description des groupe d'actions
Mais on pourrait fusionner les deux config, par pour le button;yaml on pourrait garder cette config

# buttons.yaml
label: _t(AB_buttons_label)
position: 2
previewHeight: 100px
actions:
  button:
    label: _t(AB_buttons_action_button_label)
    description: _t(AB_buttons_action_button_description)
    properties:
      text:
        label: _t(AB_buttons_action_button_text_label)
        value: _t(AB_buttons_action_button_text_default)
      link:
        label: _t(AB_buttons_action_button_link_label)
        value: https://yeswiki.net
        hint: _t(AB_buttons_action_button_link_hint)
        type: page-list
     hideifnoaccess:
        advanced: true
        label: _t(AB_buttons_action_button_hideifnoaccess_label)

Et on la compléterai avec les infos définies dans le configure

Donc la y'aurait un arbitrage à faire avec ce qu'on met dans le configure et ce qu'on met dans le yaml. Car on pourrait très bien dans configure faire

public function configure()
{
    $this->addLabel(_t("AB_buttons_action_button_label"));
    $this->addArgument("text", UrlArgument, [
        "required" => true,
        "label" => _t("AB_buttons_action_button_text_label"),
        "value" => _t("AB_buttons_action_button_text_default"),
        "advanced" => false
    ]);
}

Perso je laisserai le max dans le yaml, et mettrai juste ce qui permet le traitement automatique des arguments, donc le type, si c'est required, et si y'a une valeur par default.