Les évolutions de CFG visent actuellement 2 choses : simplifier et réduire au maximum son code, tout en permettant de l’étendre si besoin, et préparer le futur pour SPIP 2.0 et notamment pour les formulaires dynamiques.

Changements de la version 1.8

Les modifications concernent essentiellement une simplification du code pour lire et ecrire les données transmises à CFG (avec dans l’idée de peut être ajouter un jour au core de SPIP les fonctions lire_config(), ecrire_config() et effacer_config() que propose CFG).

Des jeux de tests (dits "tests unitaires") ont étés créés pour l’occasion afin de vérifier que les modifications ultérieures de CFG ne cassent pas la compatibilité sur les ces fonctions cités. Ils seront à compléter.

Un changement important :

CFG ne supporte plus l’écriture (hack) #CONFIG{expression,'',''}, à remplacer par #CONFIG{expression,#ARRAY}

Changements de la version 1.9

Uniquement pour SPIP 2.0 dev svn : les modifications concernent les formulaires publics et ajax réalisés en CFG . La syntaxe précédente #FORMULAIRE_CFG{nom} n’est plus utilisée ni fonctionnelle.

On s’appuie maintenant encore plus sur la nouvelle syntaxe simplifiée des formulaires dynamiques, nommés CVT (pour Charger, Vérifier, Traiter). Ces formulaires sont stockés dans le dossier formulaires/ (et non pas dans le dossier fonds/).

Les formulaires CVT permettent de réaliser des formulaires utilisables à la fois dans l’interface publique ou privée du site, en ajax (rechargement partiel de la page) ou non (rechargement de toute la page).

Syntaxe :
#FORMULAIRE_NOM
#FORMULAIRE_NOM{#ID}

Fonctionnement avec CFG : Lorsqu’un formulaire formulaires/xx.html ne possède pas de fonction de chargement formulaires_xx_charger() alors c’est le parseur de CFG qui est utilisé, pour charger, vérifier et traiter le formulaire.

Différences avec un formulaire CFG dans le dossier fonds/ :

• les fonds/ s’affichent dans ?exec=cfg, pas les formulaires/
• les fonds/ ont [(#ENV{_cfg_}|form_hidden)], pas les formulaires/
• en revanche, les formulaires/ ont #ACTION_FORMULAIRE{#SELF}, pas les fonds/

Exemple de formulaire CFG/CVT : Soit le formulaire : formulaires/exemple_configurer_site.html

Il est appelé par : #FORMULAIRE_EXEMPLE_CONFIGURER_SITE ou pour l’avoir en ajax (en l’encadrant d’une class ’ajax’) par : <div class="ajax">#FORMULAIRE_EXEMPLE_CONFIGURER_SITE</div>

Changements de la version 1.10

CFG ne gère plus de téléchargements de librairies, et ne s’occupe plus du selecteur de couleur.

Le plugin palette : Pour mutualiser le code du sélecteur de couleur ajouté a CFG entre plusieurs plugins, celui-ci a déménagé dans un second plugin, "Palette", fonctionnant sous SPIP 1.9.2 et SPIP 2.0 .

En conséquence, les fonds CFG qui utilisaient la classe css "cfg_couleur" pour afficher un sélecteur de couleur nécessitent maintenant le plugin "Palette". Notez bien que le plugin est optionnel, son absence ne gène pas le fonctionnement normal du formulaire, seulement la palette ne s’affiche pas.

Le plugin palette s’affiche en utilisant la classe css "palette" sur un champ de formulaire. Il est donc conseillé de remplacer la classe css "cfg_couleur" par "palette" dans les formulaires l’utilisant. Cependant, la rétrocompatibilité de la classe css ’cfg_couleur’, devenue obsolète, sera assurée quelques temps.

Changement d’api des tests de validation des champs de formulaire :

Les points d’entrée concernant les champs de formulaires ayant une classe ’type_xxx’, reçoivent maintenant les mêmes arguments que les autres points d’entrées, soit le nom du champ ainsi que l’instance de l’objet cfg. Exemple :

Permettre des actions pour un formulaire particulier :

Il était possible pour un formulaire d’utiliser une fonction de vérification pour les champs postés (comme avec les formulaires dynamiques de SPIP 2). La syntaxe change légèrement, mais il est maintenant possible de réaliser d’intégrer d’autres points d’entrées de la même manière.

Particulièrement, il est possible d’effectuer des actions post traitements (ou pre traitements). Les actions possibles sont les mêmes que celles des paramètres ou des classes css : pre_charger, charger, pre_verifier, verifier, pre_traiter, post_traiter.

Les fonctions nommées ’cfg_vue_action’ reçoivent en argument l’instance de la classe CFG :

Un cas particulier est l’action ’verifier’ qui retournait un tableau d’erreur. Ce retour est devenu obselète, il vaut mieux ajouter depuis la fonction les erreurs en utilisant la fonction ajouter_erreurs() :