Conditions et chemins de formulaire

hideIf, disableIf et requiredIf se placent sur le champ, au même niveau que type.

Propriété	Effet
hideIf	Masquer le champ si la condition est vraie.
disableIf	Désactiver son édition dans le formulaire si la condition est vraie.
requiredIf	Exiger une valeur si la condition est vraie ; la validation PHP tient aussi compte des champs masqués et éléments supprimés.

Ces conditions pilotent un formulaire. Un champ masqué ou désactivé n'est ni une permission d'API ni une garantie de secret, et sa valeur peut toujours être lue par l'appli.

Expressions

Une comparaison est [chemin, opérateur, valeur]. Opérateurs : ==, !=, <, >, <=, >=. Les alias === et !== ne promettent pas une comparaison typée stricte côté PHP : préfère les opérateurs précédents et une valeur du bon type.

Combine les expressions avec { and: [expression, ...] } ou { or: [expression, ...] }. Il ne s'agit pas de JavaScript arbitraire. Exemple :

{
  "or": [
    ["settings.mode", "==", "simple"],
    { "and": [["settings.mode", "==", "advanced"], ["settings.limit", ">", 2]] }
  ]
}

À quoi correspond un chemin ?

Contexte	Exemples
Conditions / libellés de formulaire	settings.enabled depuis la racine, @self pour le champ courant, @parent.enabled depuis son groupe ancêtre.
Lecture SDK	kapp.preferences.get('rounds[0].title') ; aucun @parent.
Migration	path dans l'ancien arbre ; @reference uniquement dans le callback d'un foreachInCollection.

Chaque @parent remonte au groupe ancêtre le plus proche. Une collection ne compte pas comme un groupe ; le groupe représentant chaque élément compte. Cette règle est partagée par le navigateur et la résolution PHP.

Collection avec groupes frères

Schéma complet à exporter depuis preferences.config.js :

{
  "type": "group",
  "groupItems": {
    "states": {
      "type": "collection",
      "collectionItems": {
        "type": "group",
        "groupItems": {
          "rules": {
            "type": "group",
            "groupItems": {
              "effect": {
                "type": "choice",
                "wuOptions": { "choices": { "none": "Aucun", "message": "Message" } },
                "default": "none"
              }
            }
          },
          "action": {
            "type": "group",
            "groupItems": {
              "text": {
                "type": "string",
                "hideIf": ["@parent.@parent.rules.effect", "!=", "message"],
                "requiredIf": ["@parent.@parent.rules.effect", "==", "message"]
              }
            }
          }
        }
      },
      "wuOptions": {
        "prototypeData": { "rules": { "effect": "none" }, "action": { "text": "" } }
      }
    }
  }
}

Depuis text, le premier @parent atteint action, le second atteint le groupe de l'élément. On descend alors dans rules.effect. Changer l'effet d'un élément ne vise pas les autres éléments.

Depuis settings.rows.<élément>.text, si settings et l'élément sont des groupes, @parent.enabled vise l'élément et @parent.@parent.enabled vise settings. N'ajoute pas un niveau pour rows. La règle se répète avec les collections imbriquées.

Une collection scalaire possède également un groupe technique par élément ; sa valeur est portée par scalarCollectionItem dans le formulaire, bien que le SDK rende une liste de scalaires.

Recette de vérification

Après compilation, tester les deux branches de chaque condition, puis ajouter, réordonner et supprimer plusieurs éléments. Vérifier qu'un champ requis visible refuse une valeur vide et qu'un champ conditionnel masqué ne bloque pas la sauvegarde. Relire les préférences dans l'appli après sauvegarde ; un bon affichage du formulaire ne prouve pas à lui seul la valeur persistée.