Comment gérer au mieux les valeurs par défaut des champs personnalisés et les journaux de paramètres de catégorie

Quelques informations

La raison pour laquelle cela se produit est que

  1. Le plugin ActivityPub définit certaines valeurs par défaut pour ces champs côté client (ici).

  2. Toutes les modifications des champs personnalisés de catégorie sont enregistrées comme des modifications de paramètres de catégorie dans le cœur (ici).

« 1 » (définir les valeurs par défaut des champs personnalisés de catégorie côté client) semble être la meilleure façon de travailler avec le pipeline des champs personnalisés de catégorie pour le moment, car l’action update de catégorie les enregistrera automatiquement, et vous voulez vous assurer que les valeurs par défaut sont définies si les champs personnalisés sont interdépendants (comme ils le sont dans le plugin AP).

Notez qu’il n’est actuellement pas possible pour un plugin de sérialiser sélectivement des champs personnalisés vers le serveur (sans monkey patching).

Compte tenu de ce qui précède, je me demande si « 2 » a du sens ? Comme David le souligne, compte tenu de la configuration actuelle du pipeline, un changement dans un champ personnalisé n’indique pas nécessairement un changement dans la configuration des paramètres de la catégorie (c’est-à-dire passer de nil à la valeur par défaut).

Je suis curieux d’entendre les avis des autres sur ce sujet. Peut-être que je manque une meilleure façon de gérer les valeurs par défaut des champs personnalisés de catégorie.

3 « J'aime »

@david Je fais remonter ce point dans votre liste. Quelle est votre intuition à ce sujet ? Si vous pensez qu’une modification de la façon dont les champs personnalisés de catégorie pourrait être nécessaire dans le cœur du système, je peux essayer. Ou peut-être que je verrai si je peux trouver une nouvelle façon de définir les valeurs par défaut pour les champs personnalisés. Ou peut-être que nous laissons tomber pour l’instant ?

Oui, c’est délicat. Je suppose que la plupart des plugins ne rencontrent pas ce problème car leur ‘valeur par défaut’ pour le paramètre de catégorie est une valeur nulle.

Aviez-vous une idée de changement d’API principal qui pourrait aider à améliorer la situation ?

Totalement non testé, mais je pense que nous pourrions peut-être y parvenir dès maintenant en utilisant un champ de saisie HTML brut (notez input en minuscules au lieu du composant \u003cInput à double liaison d’Ember).

<input
  value={{or category.custom_fields.my_field "valeur par défaut"}}
  {{on "change" this.updateMyFieldValue}}
/>

Avec cette stratégie, nous avons le contrôle sur la façon dont les valeurs sont lues/écrites dans l’instance du modèle. Ainsi, si une valeur est définie sur la valeur par défaut dans l’interface utilisateur, nous pouvons l’écrire comme ‘null’ dans les champs personnalisés :

@action
updateMyFieldValue(event){
  let newValue = event.target.value;
  if(newValue === "valeur par défaut"){
    newValue = null;
  }

  this.category.set("custom_fields.my_field", newValue);
}

(et ensuite vous supprimeriez la configuration de la valeur par défaut que vous avez décrite dans (1) de l’OP)

1 « J'aime »