[spip-dev] [spip-commit] r15806 - branches/spip-2.1/ecrire/balise

Dev
1

Désolé d'avoir modifié la sémantique précédente mais justement ce fichier possède toujours le même travers: il y a beaucoup trop de zones d'ombre dans la sémantique attendue de cette section, particulièrement importante dans le noyau de SPIP:

- le rôle des paramètres commençant par "_" n'est pas décrit
- la paramètre "forcer_request" fait-il partie de la sémantique où est-il un hack permettant le debug ?
- pour chacun des paramètres "message_erreur", "message_ok" et "message_ok_$form", s'agit-il d'une valeur déduite de la présence/absence des autres paramètres d'erreurs (ce qui serait logique mais ne me semble pas être le cas) ou bien est-ce une valeur à part (et alors comment interpréter une contradiction entre la presence de ce "message_erreur" global et l'absence de messages d'erreur spécifiques à des champs, et inversement pour "message_ok", et aussi pour "message_ok_$form", et aussi pour une éventuelle contradiction entre ces 3 paramètres généraux ?

A cette imprécision de la spec s'ajoutent des problèmes techniques:

- pourquoi faut-il échapper certaines valeurs et pas d'autres ?
- le code initial utilisait la fonction PHP Merge qui repose sur un algorithme bourré d'exceptions, avec le risque habituel de PHP de changer la sémantique de leur code sans prévenir; c'est typiquement le genre de fonctions à éviter dans les sections du code où il faut assurer clarté et compatibilité dans la sémantique de SPIP.

Committo,Ergo:Sum

2

[15780] contenait des bugs sur la prise en compte de editable, formulaire_ok et formulaire_erreur, en sus de celle deja corrigee par [15805]

On tente de retablir la prise en compte correcte depuis charger(), verifier() et traiter(), sans revert le code

Modified:

branches/spip-2.1/ecrire/balise/formulaire_.php

Details: http://trac.rezo.net/trac/spip/changeset/15806

Désolé d’avoir modifié la sémantique précédente mais justement ce fichier possède toujours le même travers: il y a beaucoup trop de zones d’ombre dans la sémantique attendue de cette section, particulièrement importante dans le noyau de SPIP:

  • le rôle des paramètres commençant par « _ » n’est pas décrit
  • la paramètre « forcer_request » fait-il partie de la sémantique où est-il un hack permettant le debug ?
  • pour chacun des paramètres « message_erreur », « message_ok » et « message_ok_$form », s’agit-il d’une valeur déduite de la présence/absence des autres paramètres d’erreurs (ce qui serait logique mais ne me semble pas être le cas) ou bien est-ce une valeur à part (et alors comment interpréter une contradiction entre la presence de ce « message_erreur » global et l’absence de messages d’erreur spécifiques à des champs, et inversement pour « message_ok », et aussi pour « message_ok_$form », et aussi pour une éventuelle contradiction entre ces 3 paramètres généraux ?

A cette imprécision de la spec s’ajoutent des problèmes techniques:

  • pourquoi faut-il échapper certaines valeurs et pas d’autres ?

La spec est assez complète et documentée, pourtant :
http://www.spip.net/fr_article4151.html
http://www.spip.net/fr_article4152.html
http://www.spip.net/fr_article4153.html

Le seul point délicat est la séparation de l’appel de verifier()&traiter() qui est réalisé en début de hit, avant toute sortie, et stocke le résultat dans un tableau récupéré par l’appel
$post = traiter_formulaires_dynamiques(true);
dans balise_FORMULAIRE__contexte()

La protection des champs saisis est expliquée dans http://www.spip.net/fr_article4151.html
« Par défaut, toutes les valeurs du tableau sont protégées pour pouvoir être insérées en toute sécurité dans l’attribut value d’un input dans le squelette du formulaire. Lorsque la valeur est elle-même un tableau, chacune de ses valeur est protégée et ainsi de suite. »

message_ok et message_erreur sont deux cas particuliers puisque non destinés à être saisis mais à l’affichage.

  • le code initial utilisait la fonction PHP Merge qui repose sur un algorithme bourré d’exceptions, avec le risque habituel de PHP de changer la sémantique de leur code sans prévenir; c’est typiquement le genre de fonctions à éviter dans les sections du code où il faut assurer clarté et compatibilité dans la sémantique de SPIP.

Oui, c’est aussi bien comme cela.
Mais la ré-écriture de code introduit toujours un nombre de bugs proportionnel au nombre de lignes réécrites.
Il n’y a qu’en testant tous les cas d’usage qu’on peut assurer l’équivalence sans modification fonctionnelle et il manque clairement des jeux de test sur cette fonction.

Cédric

3

Bonne nouvelle mais quand je clique là-dessus, j'ai

Fatal error: Cannot redeclare balise_config() in /var/shim/spipnet/Web/plugins/cfg/cfg_fonctions.php on line 34

Ca n'a probablement rien à voir avec la discussion mais ça tombe mal.

Committo,Ergo:Sum

4

*je* plaide coupable.

l'installation (que j'ai faite) du plugin mediathèque sur spip.net
provoque 2 ou 3 effets de bord passagers (dans le sens éphémères).

la mise à jour (aussi effectuée) de cfg règle le problème.

désolé.

5

Merci Denis. Je comprends que tu viens d'installer:

http://zone.spip.org/trac/spip-zone/changeset/38776/plugins/cfg/cfg_fonctions.php

et c'est un bel exemple qu'on est incapable de garantir d'avance que deux plugins vont pouvoir cohabiter sans rendre le site inopérant. Et cela a finalement à voir avec la discussion puisque cette erreur fatale est due à

http://zone.spip.org/trac/spip-zone/changeset/38757/plugins/spip-bonux-2/configurer/pipelines.php
qui s'annonce comme complément à:
http://zone.spip.org/trac/spip-zone/changeset/38756
lequel se voulait une alternative à la balise #REMPLIR que j'ai introduite dans le noyau sans provoquer d'erreur fatale quelque part ni obliger à réécrire CFG ou tout autre plugin.
A méditer.

Committo,Ergo:Sum

6

L'argumentation est biaisée, puisque si j'avais moi aussi introduit la fonctionnalité dans le core, la fonction balise_CONFIG_dist native eut été remplacée sans le moindre conflit.
Par ailleurs, on compare deux choses qui ne couvrent pas le même périmètre, puisque la proposition de bonux assure la compatiblité des squelettes utilisant #CONFIG{casier/valeur}, ce qui n'est pas le cas de la proposition autour de #REMPLIR, pour le moment du moins.

Cédric

7

* Committo,Ergo:sum tapuscrivait, le 26/06/2010 17:02:

et c'est un bel exemple qu'on est incapable de garantir d'avance que deux plugins vont pouvoir cohabiter sans rendre le site inopérant. Et cela a finalement à voir avec la discussion puisque cette erreur fatale est due à

Il me semblait que c'était le propre des surcharges des _dist et des déclarations de fonctions en PHP qui garantie que sans test (ou lecture attentive du code), on ne peut pas garantir que 2 plugins ne seront pas incompatibles entre eux.

-- RealET, trolleur ?

8

cette erreur fatale est due à

Connexion · GitLab
qui s'annonce comme complément à:
Connexion · GitLab
lequel se voulait une alternative à la balise #REMPLIR que j'ai introduite dans le noyau sans provoquer d'erreur fatale quelque part ni obliger à réécrire CFG ou tout autre plugin.
A méditer.

L'argumentation est biaisée, puisque si j'avais moi aussi introduit la fonctionnalité dans le core, la fonction balise_CONFIG_dist native eut été remplacée sans le moindre conflit.

Bien sûr, mais ce que je voulais dire ici c'est que le développeemnt de SPIP ne peut se faire sans intervenir dans le noyau, évidence qu'il semble nécessaire de rappeler.

Le pire est que le danger était connu depuis deux semaines, mais ça n'a servi à rien:

Par ailleurs, on compare deux choses qui ne couvrent pas le même périmètre, puisque la proposition de bonux assure la compatiblité des squelettes utilisant #CONFIG{casier/valeur}, ce qui n'est pas le cas de la proposition autour de #REMPLIR, pour le moment du moins.

Mon intention étant de proposer une alternative beaucoup plus légère à CFG (j'en suis à 4 Ko contre 96), j'avance à pas mesurés pour éviter de déboucher sur la même chose: un code dont 80% ne sert que dans 20% des cas.

Mais revenons à la discussion initiale. Je veux bien qu'on déporte les commentaires du code sur spipnet ou tout autre site, mais au moins il aurait fallu mettre ces URL en commentaires car rien que leur existence ne se devine pas. J'ai donc été lire

et j'en ai profité pour corriger l'orthographe et autres désagréments. Je suis quand même un peu estomaqué d'y lire ça:

Par défaut, SPIP vérifie que le formulaire posté est bien le bon pour permettre d’avoir plusieurs formulaires du même type dans une page, et ne traiter que celui qui a été soumis. La vérification est basée sur la liste des arguments passés à la balise #FORMULAIRE_XXX.

Dans certains cas où ces arguments changent suite à la saisie, SPIP peut se tromper et croire que la saisie vient d’un autre formulaire.

Ce code s'avoue donc être un bricolage pas fiable, c'est vraiment pas glorieux.

Plus loin on a:

_pipeline
Ce champ permet de demander à ce que le résultat du calcul du formulaire passe dans le pipeline mentionné, permettant son extension par des plugins.
Ce peut-être une simple chaîne, pour definir le nom du pipeline :

$valeurs['_hidden'] = "monpipeline";

ou un tableau de deux valeurs, pour préciser des arguments à passer au pipeline :

$valeurs['_hidden'] = array("monpipeline",array('arg1'=>'unevaleur',...));

Il me semble qu'il faudrait remplacer "_hidden" par "_pipeline" sinon c'est incompréhensible.

Committo,Ergo:Sum