saisies

Commit Graph

Author	SHA1	Message	Date
Maïeul	1f461dea2f	`a677759` provquait parfois un warning	2 years ago
Maïeul	a677759cc6	Lors de la verification PHP des affichages conditionnelles des saisies, passer le tableau d'options globales aux sous saisies, histoire de ne pas perdrer l'option globale `afficher_si_avec_post`.	2 years ago
Maïeul	8300b8139e	Suite discussion avec @rastapopoulous , unifier le nom des options qu'elles soient globales ou par saisies. On garde `afficher_si_avec_post`. On mappe pour rétrocompatibilité `poster_afficher_si` Ping @tcharlss Note : un grep sur git.spip.net ne donne aucune occurence de poster_afficher_si	2 years ago
Maïeul	1991948140	amélioration du phpdoc pour y voir plus clair sur les options saisies_veirfier_afficher_si()	2 years ago
tcharlss	b2d559c812	Également une option globale pour conserver les valeurs de toutes les saisies masquées	2 years ago
tcharlss	ca8ed167fa	Nouvelle option `afficher_si_avec_post` qui permet de conserver les valeurs des saisies cachées.	2 years ago
RastaPopoulos	ed8fab3352	Après des jours de recherche… Gros bug avec un énième (c'est récurent au fil des années) oubli de prendre en compte quand les champs ne sont pas des noms simples mais des sous-tableaux. Là c'est quand on cherche à vider les valeurs de request des champs masqués donc désactivés par afficher_si. Ça faisait un set_request() basique, qui ne faisait donc rien si le nom était tableau[index]. Tout comme il y a saisies_request, on fait donc une fonction saisies_set_request qui fait ça proprement et mutualisé. MAIS comme dit dans le ticket #29 ça n'a strictement rien de propre à Saisies ! On devrait donc prendre en compte ces cas directement dans _request() et set_request() du core, d'après moi.	2 years ago
Matthieu Marcillaud	17d5f5349b	Notice PHP -- (imbrication de ternary operators)	2 years ago
RastaPopoulos	14fe3a4a3c	Dans les tests de condition en PHP, on sait moins facilement si on attend un tableau ou pas, suivant comment ça a été stocké en base (pas pareil en Formidable et Champs Extras pour l'instant). Donc quand on récupère la valeur, on teste si c'était une saisie de type tabulaire ou pas puisqu'on sait ici de quelle saisie il s'agit ! Et dans ce cas on force toujours en tableau. Au passage on renomme des variables pour être plus explicite : saisies_par_nom et valeur au lieu de champ	2 years ago
Maïeul	b41d105db7	no_arobase : tests strict en se basant sur null, car on peut vouloir comparer une chaine vide	3 years ago
Maïeul	39f5ed53b9	Nouvelle fonction pour les afficher_si (uniquement en PHP) : pouvoir ne pas passer explicitement un champ. Dans ce cas on testera avec la valeur du dernier paramètre (nouvellement créé) de saisies_evaluer_afficher_si. Exemple avec formidable ts : - le afficher si est '> 130'; - le dernier paramètre est "120" > le resultat sera faux.	3 years ago
maieul@maieul.net	9d441c1608	notice	3 years ago
maieul@maieul.net	de9ee7bc76	afficher_si pour la saisie cvt_upload. Permet avec la syntaxe @fichiers_1@:TOTAL > 2 d'afficher quelque chose si on a plus de 2 fichiers envoyé	3 years ago
maieul@maieul.net	9bf3d2a0cd	afficher_si : nouvelle syntaxe '@checbox_x@:TOTAL > 3', permet de tester si le nombre total de case cochée est supérieur à 3	3 years ago
maieul@maieul.net	824d3b8493	un static qui ne retournait pas le bon résultat + ne prenait pas en compte une récursivité > un static qui n'en vaut pas la peine	3 years ago
maieul@maieul.net	ec802fe811	un code qui s'était retrouvé doublonné avec la fusion de branche	3 years ago
maieul@maieul.net	664c52a0ec	tester systématiquement la syntaxe des conditions avant d'essayer de les transformer en js/php + accepter les conditions false / true	3 years ago
maieul@maieul.net	b4997c033f	evaluer_afficher_si (php). Tenir compte des descriptions de type @tableau[a][b]@	3 years ago
maieul@maieul.net	0b14daf98f	un peu de code refactoring	3 years ago
maieul@maieul.net	e1b9aa100e	Report r116075 Ne pas permettre en PHP d'executer du code arbitraire via afficher_si (jusqu'à maintenant possible en rusant sur les tests alternatifs).	3 years ago
maieul@maieul.net	87c531e7ba	Un certains nombres de fonctions soit disantes propres à l'évaluation PHP seront aussi utilisées pour l'évaluation JS : on en aura besoin pour les cas @config@ et @plugin@.	3 years ago
maieul@maieul.net	86e8e92e52	La lecture des config lorsqu'on a @config:xxx@ est mis dans une fonction à part, servira pour la suite niveau JS. On en profite pour optimiser un peu : puisqu'on est deja "champ" par "champ" un preg_match() suffit.	3 years ago
maieul@maieul.net	1ad8dcc295	saisies_tester_condition_afficher_si() prend directement en compte la négation (utile pour la suite, mutualisation de code)	3 years ago
maieul@maieul.net	bf07379967	traiter le cas @plugin:xxx@ comme un type particulier de champ	3 years ago
maieul@maieul.net	12f8ccaa31	code inutile	3 years ago
maieul@maieul.net	e8b4f40441	bons noms de variable	3 years ago
maieul@maieul.net	2685734713	avec la future réécriture js, le traitement des config sera un cas spécifique de champ => plus besoin de fonction à part (pour le moment	3 years ago
maieul@maieul.net	26964c5767	mettre toute la partie de parsage des conditions dans une fonction à part	3 years ago
maieul@maieul.net	f2a6aedb85	prologomène : séparer le fichier des afficher_si en 3 parties : commun/js/php	3 years ago
maieul@maieul.net	88c7fc863a	Ne pas permettre en PHP d'executer du code arbitraire via afficher_si (jusqu'à maintenant possible en rusant sur les tests alternatifs).	4 years ago
maieul@maieul.net	4e196c9423	afficher_si : ajouter automatiquement une classe pour savoir si masqué/visible en fonction d'un affichage conditionnel.	4 years ago
nicod@lerebooteux.fr	4f199eb012	Si on met un retour chariot (donc une ligne vide) dans Affichage conditionnel, ça plante tout le javascript généré (en gros ça ferme directement un if ouvrant). Ajout d'un trim pour éviter ces cas là (et suppression du deuxième isset, il l'est forcément) Merci Anne-Marie pour le signalement :)	4 years ago
maieul@maieul.net	836e9b85ac	Les sélecteurs jquery pour basculer les required en cas d'afficher_si n'allaient pas: - pas génériques - ne testaient pas la présence de required, donc pas logique - hypers lourds et pouvaient provoquer des lagues importants en cas d'afficher_si multiple On modifie donc ces selecteurs. - Si le test d'affichage de la saisie n'est pas validé, on cherche tous les élèments inclus dans la saisie qui ont attribut required, et on modifie cet attribut required en data-afficher_si_required - Si le test d'affichage de la saisie est validé, on cherche tous les élèments inclus dans la saisie qui ont attribut data-afficher-sirequired, et on modifie cet attribut en required Bref, un bete drapeaux de switch. Merci Rasta d'avoir signalé les problèmes :)	4 years ago
maieul@maieul.net	ebee6b7580	quand on fait des exclusions, il faut les faires sur les bons selecteurs	4 years ago
maieul@maieul.net	f240c55fd4	revert r115020, il faudrait échapper les retours lignes eux mêmes, ca va encore complexifier les choses	4 years ago
maieul@maieul.net	34cd34b9de	Bugfix Si on a un champ checkbox multiple, les input individuel ne doivent jamais avoir de required. Or, si ce checkbox multiple se trouvait dans un fiedset conditionné par afficher_si, le js ajoutait ce required. On ajoute donc une exception. Bon, c'est encore du bricolage, faut vraiment qu'un de ces 4 on trouve une méthode propre pour gérer ce genre de problème.	4 years ago
maieul@maieul.net	f1eea97796	retour ligne pour y voir plus clair dans le debugage	4 years ago
nicod@lerebooteux.fr	e6fed661e7	Gérer le cas des textarea avec barre d'édtion (encapsulés dans un markitup). Dans certains cas (chargement du formulaire en ajax), le js markitup peut être chargé avant le js afficher_si, qui ne trouve donc plus les textarea pour manipuler leur attribut required.	4 years ago
maieul@maieul.net	f908ec9b5c	parfois la condition passée à saisies_evaluer_afficher_si() est juste une valeur booleenne, ce qu'on autorise du coup. C'est le cas notamment si on teste @plugin:xxx@	4 years ago
maieul@maieul.net	2d114d952c	ortho	4 years ago
maieul@maieul.net	e62c499d6a	affichage_conditionnel avec des valeurs numériques: - même test en php qu'en js - prendre en compte la possibilité de test sur inférieur / supérieur etc	4 years ago
maieul@maieul.net	b173967d3e	évaluer correctement les @config:xx@ et avoir des tests unitaires qui testent vraiment ce qu'ils annoncent tester	4 years ago
maieul@maieul.net	3a3daf523d	php doc : préciser la différence entre saisies_tester_condition_afficher_si_array() et saisies_tester_condition_afficher_si_string()	4 years ago
maieul@maieul.net	10f06166ab	formatage code	4 years ago
maieul@maieul.net	5280c2f361	si ca matche pas au niveau de la syntaxe de l'affichage conditionnel, alors on considère que la condition est forcément remplie mais on met un message de log d'erreur	4 years ago
maieul@maieul.net	269cf1b25a	meilleure php doc, puisque les opérateurs sont expliqués plus haut, pas la peine de repeter ici l'info	4 years ago
maieul@maieul.net	823e1c3cd6	maintenant qu'on a un vrai parseur pour l'évaluation des conditions en php, il n'est pas la peine de remettre un vérificateur de sécurité, puisqu'on ne fait plus de eval() direct	4 years ago
maieul@maieul.net	24473b7f66	deux constantes pour définir les effets de masquage/affichage de champ avec afficher_si	4 years ago
maieul@maieul.net	c560208ec3	Si un afficher_si porte sur un fieldest, supprimer l'attribut require de tout les input dedans, et pas seulement ceux de premier niveau, puisque de toute facon les inputs sont forcément dans un div englobant. Merci à 1138 pour le signalement. https://contrib.spip.net/Formidable-le-generateur-de-formulaires#comment500015-500011	4 years ago
maieul@maieul.net	ff3be48811	soyons précis sur le select de radio	4 years ago

29 Commits (1f461dea2f9a8a50a12cbc0ec68ed047c3f2f637)