Futurs refactoring à discuter avec les usagers

[seballot]

Voici une liste de potentiel refactoring, mais qui auront des impacts sur les utilisateurs, surtout en terme de retrocompatibilité

Profiter d'un sprint pour discuter collectivement du bien fondé de ces idées

1. Style & Thèmes

Descriptif (voir #1026 pour les détails)

• Modifier le HTML pour n'avoir que des classes descriptives
• Repartir de zéro niveau CSS, pour avoir un thème de base neutre et personnalisable. Faciliter les customisations poussées via la segmentation du code CSS)

Impact pour les usagers

• Les personnalisations graphiques avancées (notamment via l'ajout de CSS) seront certainement en partie cassés

2. Abandon de la syntaxe ***bf_titre***45*** pour les Formulaire

Descriptif

• Stocker sous forme de JSON la configuration du formulaire
• Bonus: stocker le formulaire comme une page plutot que dans un table dédiée
• Bonus: refaire le constructeur de formulaire pour qu'il soit directement construit à partir de la déclaration des classes php Field (ça permettrait aussi une prévisualisation hi-fi)

Impact pour les usagers

• Plus la possibilité de faire simplement des copier coller, ou alors faudra redévelopper un truc pour pouvoir éditer un JSON plutot qu'un text avec des ***
• Peut etre certaines options obscure ne sont pas encore dans l'interface graphique, on les perdrait alors. Sauf pareil si on fait un éditeur JSON pour customiser à la mano le formulaire

3. Champ générique "Enum/Choice" dans le Formulaire

Descriptif

• Merge les champs liste, checkboxes (normal, drag-drop, tag), radio, externalliste, externalcheckboxes, externalradio, pour avoir un seul champs générique Enum, plus facilement configurable
• rendre accessible toute la conf via l'interface graphique plutot que via des paramètres, par exemple pour l'affichage d'un filtre des options, ou d'un case "cocher tout"

Impact pour les usagers

• nouveau champ qui remplacera les anciens

[vincent-lucy]

On me dit dans l'oreillette que @ppom0 as des commits à pusher...