Pouvoir modifier un type de saisie

J'ai une projet où je veux remplacer des @input@ par des sous saisies spécifiques de type @toto@.

Du coup je compte écrire une fonction qui

1. Lise les saisies et traitements d'une formulaire et autres réglages
2. Recherche les occurences de la saisie @input@ et remplace par @toto@ y compris dans les afficher_si
3. Corrige les réponses enregistrés

Evidemment je la mettrait à dispo, et du coup je pensais aussi mettre un petit formulaire pour permettre le remplacement facile (genre transformer les select en radio et reciprorquement).

La question que je me pose : dans formidable ou dans un sous plugin ?

Argument en faveur d'un plugin à part : opération pas anodine, à faire en conscience + ne pas alourdire un interface deja bien chargé.

Oui ça me parait assez spécifique, encore plus que pouvoir changer le type d'une saisie précise (ce qui à la limite pourrait être dans les fonctionnalités de base et là aussi faut ensuite changer des choses un peu partout)

heu... on a pas du se comprendre car c'est exactement ce que je propose/désir faire.

J'ai la saisie @select_1@, je veux la transformer en @radio_xxx@.

Ah je croyais que tu voulais changer toutes les saisies "input" d'un formulaire en saisies "toto", pour un formulaire donné, un truc dans ce genre.

Moi ce qui m'intérerroge c'est pas tant ce qu'il y a à remplacer derrière c'est déjà l'interface, où et comment le plus intuitivement possible. Parce qu'on sait qu'il va y avoir des changements à faire en cascade derrière mais c'est pas forcément le plus compliqué. Quoi que, ça veut dire possiblement changer les réponses aussi qui pouvaient déjà être liés au champ en question etc.

D'ailleurs on parle de deux choses liées mais différente là changer la définition du type, ce qui peut changer alors les options (certaines disparaissent, d'autres aparraissent et faut possiblement les remplir par défaut si jamais elles sont obligatoires). Et changer le nom du champ (ce qui ne serait pas obligatoire mais ça peut se faire.

Champs Extraas par ex permet le deuxième de définir soi-même le nom du champ et pouvoir le changer à tout moment (et ça fait alors des actions en cascade si on le change vu que faut changer des trucs dans la base).

"Quoi que, ça veut dire possiblement changer les réponses aussi qui pouvaient déjà être liés au champ en question etc." oui c'est ce que je disais.

Pour l'interface, j'imaginais un truc hyper simple en fait

1. Un select sur la liste des champs
2. Un select sur les types dispo
3. Un bouton valider

Oui tu a raison formellement changer le type et changer le nom n'est pas la même chose. Mais dans formidable les 2 se confondent.

Cela étant du coup, effectivement il faut du coup envisager de découper en deux :

• une fonction dans saisies qui change le nom (partout)
• une fonction dans formidable qui trouve le nouveau nom en fonction du nouveau type, puis qui appele la fonction ci-dessus, puis qui fait tout le post traitement (changement des réponses en bases, changement des réglages dans les traitements, etc)

Après tu as raison, cela implique aussi des modifs d'options, potentiellement. Et là du coup on a plusieurs solutions :

• soit on on fait confiance à l'utilisateur pour régler cela après
• soit on fait encore plus confiance et on se dit que l'utilisateur fera pas de transtypage sans qu'il y ait une équivalence fonctionnelle (par exemple entre radio et select, ou entre input et une saisie héritière)
• soit dans le formulaire lorsque la personne à choisi le nouveau type, et bien on lui propose immédiatement le constructeur de saisie du nouveau type:
  • reprend le defaut du nouveau type
  • et les options de l'ancien

La troisième option me parait la plus propre.

(note : pour ma part je n'ai pas besoin du formulaire, mais bon quitte à coder le background)

Et si on code cela bien, après on pourra envisager l'étape suivante, qui est la nomination des champs.

La nuit portant conseil, voici les conclusions auxquelles je suis arrivé.

Formulaire de transtypage (#FORMULAIRE_TRANSTYPER_SAISIE)

CVT en multi étape

1. Choix de la saisie à transtyper et choix du nouveau type
2. Constructeur de saisie du nouveau type pré rempli avec valeurs des options de la saisie si existante dans le nouveau type + les defaut du nouveau type (surchargé par options de l'ancienne saisie)

A priori ce formulaire n'est pas spécifique à formidable au niveau ergonomie. Par contre le traitement est propre à chaque constructeur (avec Formidable, modifier les traitements par exemple.). Du coup en fin de traiter() on appelle un pipeline. Le formulaire recoit en arguments

1. Les saisies
2. Un tableau d'options (qui du coup dépendra de chaque usage, typiquement dans formidable on aura l'id_formulaire)

Fonctions dans saisies

1. saisies_remplacer($saisie, $nom_ancienne_saisie, $nouvelle_saisie) return $saisies_modifiees
2. saisies_renommer($saisie, $ancien_nom, $nouveau_nom) return $saisies_modifiees
3. saisies_remplacer_et_renommer($saisie, $nom_ancienne_saisie, $nouvelle_saisie) concaténation des deux précédents + s'occupe de remplacer automatiquement les @xxx@

Je crois que pour le reste on a tout ce qui faut dans formidable/saisies

pré rempli avec valeurs des options de la saisie si existante dans le nouveau type + les defaut du nouveau type

Voilà je pensais à ça, pour s'assurer que dès le changement, il ne manque aucune option obligatoire, exactement comme lorsqu'on insère une toute nouvelle saisie.

Mais du coup je vois pas forcément l'intérêt d'afficher ensuite le constructeur de la saisie du nouveau type, si on s'est déjà assuré que tout est rempli au maximum.

Le formulaire pourrait très bien ne comporter que la première étape, choisir la saisie et le nouveau type, et hop ça reste tout simple. On s'assure bien que tout est rempli, donc si on veut modifier, on a déjà le constructeur pour ça : on retourne dans l'interface habituelle une fois que c'est fini, pas besoin d'une deuxième interface qui fait la même chose.

L'intérêt de la deuxième étape est double

1. Si jamais le changement de type implique aussi un changement de réglage (par exemple passage de select à radio peut impliquer de supprimer des niveaux dasn data data)
2. Parce que ta nouvelle saisie pourrait avoir des options non obligatoire mais qu'il pourrait être utile de modifier tout de suite.

Je trouve que vu l'enjeu d'une migration de type de saisie, comme ce n'est pas anodin, il est bon d'accompagner l'internaute en lui demandant explicitement une vérification.

(et que pense tu du reste )

saisies_modifier existe déjà et permet déjà de changer de type ET de nom aussi https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/inc/saisies_manipuler.php#L203

saisies_modifier(
    $saisies,
    $ancien_nom,
    array('options'=>array(
    	'nom'=>'autre nom',
        'nouveau_type_saisie' => 'autre type'
    )
)

oui mais est-ce que cela supprime automatiquement les options qui ne sont plus utiles ?

Ah mais $nouvelle_saisie dans ton exemple plus haut, c'est "une saisie" ou "un TYPE de saisie" ? C'est pas clair :)

Dans ce cas faudrait plutôt l'appeler : saisies_transtyper($saisies, $id_ou_nom_ou_chemin, $nouveau_type) et que cette fonction cherche la saisie à modifier, fusionne avec les défauts du nouveau type et appelle ensuite saisies_modifier (qui sait déjà renommer)

si ce n'est pas le cas (et en vérifiant cela ne l'est pas) on a deux options

• ajouter un paramète pour dire les options à supprimer
• créer saisies_remplacer()

la seconde solution évite d'avoir des arguments tarabisctoés.

Une autre solution serait de "laisser" les options inutilisé, mais cela me parait pas propre, notamment si dans le futu on rajouter des options à la nouvelle saisie.

Pour le renommage, vu que saisies_modifier le permet déjà, c'est là qu'il y a un manque déjà dans l'actuel non ? Il faudrait que dans cette fonction directement, si on détecte que le nom est changé (que celui de $modifs est différent de l'ancien), alors il faut lancer une recherche/remplacement dans tout le tableau $saisies

Aussi au passage, ça fait longtemps que j'aimerais que cette fonction ait un nouvel argument permettant de dire si on écrase tout ou qu'on fusionne. Actuellement $modifs c'est censé être TOUT le nouveau tableau, mais il pourrait y avoir un argument $fusion=false et si true, alors on mélange, ce qui permet alors de passer des modifs sans connaitre l'ensemble du tableau à mettre.

Pour le renommage, vu que saisies_modifier le permet déjà, c'est là qu'il y a un manque déjà dans l'actuel non ? Il faudrait que dans cette fonction directement, si on détecte que le nom est changé (que celui de $modifs est différent de l'ancien), alors il faut lancer une recherche/remplacement dans tout le tableau $saisies

C'est une option aussi, mais je me méfie des fonctions qui font tout ^^. Ca devient galère après à interpréter/modifier.

Actuellement $modifs c'est censé être TOUT le nouveau tableau

a ca ja'vais pas vu au survole rapide du code. Du coup la raison d'être de saisies_remplacer() tombe

il pourrait y avoir un argument $fusion=false et si true, alors on mélange, ce qui permet alors de passer des modifs sans connaitre l'ensemble du tableau à mettre.

avec un array_merge? oui pourquoi pas, mais je suis pas sur que l'usage soit là, notamment car cela gerera mal les suppression.

Conclusion temporaire pour moi

1. Modifier le phpdoc de saisies_modifier pour préciser ce que sont les modifs (un remplacement brutal)
2. Ajouter le changement de nom (quitte à déporter pour clarté dans une fonction à part)
3. Ajouter des tests unitaires (en fait faire des tests unitaires en amont), parce que c'est quand même des choses casses gueules.

Si si l'option de fusion est très utile, moi j'ai eu plein de cas où je devais juste remplacer une ou deux options rapidement, SANS avoir déjà sous la main la description complète de la saisie dans laquelle je voulais changer ça. Et donc obligé alors d'aller chercher la saisie complète, modifier des options dedans, et tout renvoyer à saisie_modifier. Alors qu'avec l'option de fusion, j'aurais juste eu à envoyer un $modifs avec juste une ou deux lignes dedans.

saisies_transtyper($saisies, $id_ou_nom_ou_chemin, $nouveau_type, $renommer_auto=false) {
// - cherche la saisie et récupère son contenu
// - fusionne son contenu avec les défauts du nouveau type demandé et en supprimant les inutiles pour en faire un tableau $modifs
// - si $renommer_auto=true, renomme la saisie suivant le nouveau type (avec le bon numéro)
// - appelle saisies_modifier($saisies, $id_ou_nom_ou_chemin, $modifs)
}

saisies_modifier($saisies, $id_ou_nom_ou_chemin, $modifs, $fusion=false) {
// - si $modifs contient un changement de nom, lancer une recherche/remplacement dans tout $saisies (peut être dans une fonction séparée qu'on appelle là)
// - si $fusion=true, ne pas remplacer entièrement par $modifs mais fusionner avec l'existant (permet de changer juste quelques options rapidement)
}

si $renommer_auto=true, renomme la saisie suivant le nouveau nom

tu veux dire le nouveau type ?

pour le reste cela m'a l'air de tenir le route :)

Oui suivant le nouveau type pardon

bien, y a plus qu'à :)

Ça prendrait en compte les afficher_si aussi, j'imagine ?

Pour ce qui est de changer les identifiants des champs oui, c'est le but du rechercher/remplacer mais… en fait c'est possiblement plus compliqué que ça @maieul car parfois ya des conditions d'afficher_si qui sont propres à un type de champ, et s'il change c'est plus valable (IN etc). Après je sais pas si ça doit géré jusqu'à ce détail…