afficher_si sur des champs (pas extra!)

En travaillant sur formidable#58 (closed) je suis tombé sur un cas où le comportement d'afficher_si pose questions.

Attention c'est technique !

Pour résumer ce qui se passe

• lorsqu'on utilise saisies_verifier(), on met à null (et pas à chaine vide !) toutes les saisies masquées pour cause d'afficher_si
• ce comportement est lié au fait que afficher_si a d'abord été défini pour formidable, et donc dans formidable on n'enregistre pas les champs null alors qu'on enregistre les champs avec une chaine vide. Cela permet aussi d'éviter les erreurs sur les champs masqués qui ne répondraient pas à tel ou tel vérification programmé
• En revanche, pour les véritables objet SPIP, c'est l'inverse (!) :
  • si pour un champ donné la valeur en _request est null, objet_modifier_champs() ne modifie pas le champ en base
  • en revanche si pour un champ donné la valeur en _request est '', on modifie en base (et donc on vide un champ).
• Concrètement, cela veut dire que pour un objet SPIP, un champ masqué par afficher_si aura toujours sa vieille valeur en base
• coté champ extra j'avais corrigé cela il y a quelques mois par un commit qui avait jasé (car il était un peu obscure, mais c'est aussi parce que cextras n'utilise pas vraiment l'API de saisies, enfin pas totalement !)
• mais il me semble qu'en réalité cela devrait être géré nativement quelque soit la manière dont on déclare le champ

Proposition

• on peut très bien rétablir à '' les champs masqués par afficher_si dans le pipeline pre_edition
• ca casserait éventuellement le comportement historique, mais il me semble qu'il relevait d'un bug
• et on peut annuler la case avec l'option afficher_si_avec_post

A vos avis sur la proposition.