[SPIP Zone] CFG : on et pourquoi pas off ?

Jonathan · Février 7, 2010, 1:54

Bonjour,

J'ai une première fois posé cette question (de façon plus succincte) sur la liste spip-user, mais peut-être cette liste ci est finalement plus adaptée. Désolé pour le doublon en tout cas.

J'utilise CFG pour configurer un plugin de mon cru. Il s'agit de choisir à l'aide de checkboxes quels champs seront utilisés pour mes nouveaux objets. Tout fonctionne bien, je n'ai pour ainsi dire aucun problème (merci Spip-contrib !).

Ma question concerne plutôt une (non) fonctionnalité.
Si la checkbox est cochée, #CONFIG{prefixe/bla} me retourne "on".
Si la checkbox n'est pas cochée, #CONFIG{prefixe/bla} me retourne "", c'est à dire rien.

Je peux comprendre l'intérêt de ce fonctionnement (notamment en rapport aux filtres de test sur les balises), mais je le trouve incomplet. Car en effet, si CFG n'est pas installé sur le site #CONFIG{prefixe/bla} me retourne également "".

Comment distinguer alors la situation où aucun choix n'a été fait (CFG non installé), et la situation où un choix négatif à été fait (la case est volontairement décochée) ?

La seule manière à mes yeux est que #CONFIG me retourne "off" si la case est vide... non ?

Bon dimanche à tous,
Jonathan

Pierre_FICHES · Février 7, 2010, 2:04

Le 7 févr. 10 à 14:54, Jonathan a écrit :

Bonjour,

J'ai une première fois posé cette question (de façon plus succincte) sur la liste spip-user, mais peut-être cette liste ci est finalement plus adaptée. Désolé pour le doublon en tout cas.

J'utilise CFG pour configurer un plugin de mon cru. Il s'agit de choisir à l'aide de checkboxes quels champs seront utilisés pour mes nouveaux objets. Tout fonctionne bien, je n'ai pour ainsi dire aucun problème (merci Spip-contrib !).

Ma question concerne plutôt une (non) fonctionnalité.
Si la checkbox est cochée, #CONFIG{prefixe/bla} me retourne "on".
Si la checkbox n'est pas cochée, #CONFIG{prefixe/bla} me retourne "", c'est à dire rien.

Je peux comprendre l'intérêt de ce fonctionnement (notamment en rapport aux filtres de test sur les balises), mais je le trouve incomplet. Car en effet, si CFG n'est pas installé sur le site #CONFIG{prefixe/bla} me retourne également "".

Comment distinguer alors la situation où aucun choix n'a été fait (CFG non installé), et la situation où un choix négatif à été fait (la case est volontairement décochée) ?

La seule manière à mes yeux est que #CONFIG me retourne "off" si la case est vide... non ?

peut-être :
[(#PLUGIN{cfg}|non)le plugin cfg n'est pas installé]

Jonathan · Février 7, 2010, 2:15

peut-être :
[(#PLUGIN{cfg}|non)le plugin cfg n'est pas installé]

Ah oui. Il y a cette possibilité... Mais ça implique de faire des tests imbriqués : si cfg est présent > si la cache est cochée... un peu plus lourd quand même.

Merci ! Mais ça veut dire aussi que c'est impossible ?

Et avec #SAISIE non plus ?

Jonathan · Février 7, 2010, 2:25

Et avec les pipelines ? Il n'y aurait pas une solution ?

Par exemple de lancer un script PHP qui attribuerait, après chaque envoi de formulaire, la valeur off à chaque champs vide directement dans la table spip_meta...

Il doit bien avoir moyen de faire ça, non ?
Quelqu'un pourrait me donner une ou deux pistes (je maîtrise pas vraiment les pipelines) ?

Merci d'avance !

3c28660158d1d8be67ae · Février 7, 2010, 2:54

Le 7 février 2010 15:25, Jonathan a écrit :

Et avec les pipelines ? Il n'y aurait pas une solution ?

Par exemple de lancer un script PHP qui attribuerait, après chaque envoi de
formulaire, la valeur off à chaque champs vide directement dans la table
spip_meta...

Cela ne ce passe-t-il pas pas dans le fichier cfg/saisies/oui_non.html ?
<code>
<input type="radio" name="#ENV{nom}" class="radio"
id='champ_#ENV{nom}_non'[ (#ENV{valeur}|non)checked='checked']
value='' />
</code>

Il doit bien avoir moyen de faire ça, non ?

En valuant[1] value à 'non' peut-être ?

*http://dictionnaire.phpmyvisites.net/definition-Valuer-13683.htm

--
@plus

Jacques

Pour les lyonnais++ spip-lyon@rezo.net http://spip-party.net/-Lyon-

Pierre_FICHES · Février 7, 2010, 3:46

Le 7 févr. 10 à 15:25, Jonathan a écrit :

Par exemple de lancer un script PHP qui attribuerait, après chaque envoi de formulaire, la valeur off à chaque champs vide directement dans la table spip_meta...

si c'est du cvt rien n'empêche que traiter écrive une meta ...

ecrire_config('nom,'valeur');

RealET · Février 7, 2010, 4:08

* Jonathan tapuscrivait, le 07/02/2010 14:54:

Bonjour,

J'ai une première fois posé cette question (de façon plus succincte) sur
la liste spip-user, mais peut-être cette liste ci est finalement plus
adaptée. Désolé pour le doublon en tout cas.

J'utilise CFG pour configurer un plugin de mon cru. Il s'agit de choisir
à l'aide de checkboxes quels champs seront utilisés pour mes nouveaux
objets. Tout fonctionne bien, je n'ai pour ainsi dire aucun problème
(merci Spip-contrib !).

Ma question concerne plutôt une (non) fonctionnalité.
Si la checkbox est cochée, #CONFIG{prefixe/bla} me retourne "on".
Si la checkbox n'est pas cochée, #CONFIG{prefixe/bla} me retourne "",
c'est à dire rien.

Je peux comprendre l'intérêt de ce fonctionnement (notamment en rapport
aux filtres de test sur les balises), mais je le trouve incomplet. Car
en effet, si CFG n'est pas installé sur le site #CONFIG{prefixe/bla} me
retourne également "".

Comment distinguer alors la situation où aucun choix n'a été fait (CFG
non installé), et la situation où un choix négatif à été fait (la case
est volontairement décochée) ?

La seule manière à mes yeux est que #CONFIG me retourne "off" si la case
est vide... non ?

Non.
C'est le html qui veut que si la case est vide, ça renvoie rien.

Tu peux utiliser le 2e paramètre de #CONFIG qui indique la valeur par défaut si ça renvoie rien :
[(#CONFIG{prefixe/bla,on}|=={on}|oui) ce que tu veux ]

Comme ça, ton plugin aura un comportement par défaut identique aux default= du fond de config ce qui fera que non configuré aura un comportement identique à configuré par défaut.

--
RealET

larmarange · Février 7, 2010, 4:20

Pour faire suite à la discussion sur on et pas off, je m'aperçois d'une incohérence avec la saisie oui_non du plugin saisies.

En effet, cette saisie renvoie 'on' ou rien, comme ce qui est évoqué pour CFG. Par contre, pour déterminé si un bouton est sélectionné ou non, elle regarde si la valeur envoyée à la saisie est 'oui' ou 'non'.

Ne peut-on pas avoir deux saisies ?
- Une saisie oui_non qui renvoie 'oui' ou 'non'.
- Une saisie on_off qui renvoie 'on' ou ''

Joseph

RealET · Février 7, 2010, 4:29

* Joseph tapuscrivait, le 07/02/2010 17:20:

Pour faire suite à la discussion sur on et pas off, je m'aperçois d'une
incohérence avec la saisie oui_non du plugin saisies.

En effet, cette saisie renvoie 'on' ou rien, comme ce qui est évoqué
pour CFG. Par contre, pour déterminé si un bouton est sélectionné ou
non, elle regarde si la valeur envoyée à la saisie est 'oui' ou 'non'.

Ne peut-on pas avoir deux saisies ?
- Une saisie oui_non qui renvoie 'oui' ou 'non'.
- Une saisie on_off qui renvoie 'on' ou ''

Par contre, dans le code, il y a :
#SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}}

qui ramené à un squelette donne :

[(#CONFIG{prefixe/bla}|is_null|oui) Là, on n'a encore rien enregistré avec la config ]

--
RealET

marcimat · Février 8, 2010, 9:09

On 07/02/2010 17:20, Joseph wrote:

Pour faire suite à la discussion sur on et pas off, je m'aperçois d'une
incohérence avec la saisie oui_non du plugin saisies.

En effet, cette saisie renvoie 'on' ou rien, comme ce qui est évoqué
pour CFG. Par contre, pour déterminé si un bouton est sélectionné ou
non, elle regarde si la valeur envoyée à la saisie est 'oui' ou 'non'.

Non non... [ (#GET{valeur}|oui)checked='checked'] veut dire : si valeur n'est pas vide... et [ (#GET{valeur}|non)checked='checked'] : si valeur est vide... Précisément ce GET est déterminé par un truc complexe :
#SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}} qui veut en gros dire que si #ENV{valeur} n'est pas défini ; ie n'a jamais été encore enregistré, donc renvoie NULL, alors on lui affecte la valeur par défaut passée à la saisie {defaut=on} par exemple, sinon sa valeur.

Ne peut-on pas avoir deux saisies ?
- Une saisie oui_non qui renvoie 'oui' ou 'non'.
- Une saisie on_off qui renvoie 'on' ou ''

C'est une possibilité, mais perso je préfère on/'' qui permet d'écrire [(#ENV{xx}|oui) ... ], sinon, il faut écrire [(#ENV{xx}|=={oui}|oui) ... ]

----
Dans le cadre de CFG, qui n'a en fait rien à voir avec saisies, il s'agit là d'attribuer une valeur par défaut à une configuration, avant que le formulaire de configuration ait été soumis. C'est un problème courant avec CFG. La solution qu'on utilise assez fréquemment est de créer les valeur par défaut de configuration à l'installation du plugin, via la fonction ecrire_config() par exemple, ou ecrire_meta() dans le cas ou le plugin peut ne pas dépendre de cfg.

ecrire_config('monplugin', array(
  'couleurs' => array(
    'base' => 'ffffff',
    'police' => '000000',
  ),
  ));

ecrire_meta('monplugin', serialize(array(
  'couleurs' => array(
    'base' => 'ffffff',
    'police' => '000000',
  ),
  )));

--
MM.

larmarange · Février 8, 2010, 9:22

Le 08/02/2010 09:09, Matthieu Marcillaud a écrit :

C'est une possibilité, mais perso je préfère on/'' qui permet d'écrire
[(#ENV{xx}|oui) ... ], sinon, il faut écrire [(#ENV{xx}|=={oui}|oui) ... ]

Si on passe la valeur 'off' au paramètre xx, est-ce que [(#ENV{xx}|non)...] fonctionne ? Dans ce cas, y a-t-il un inconvénient à stocker dans xx la valeur 'off' plutôt que '' ?

rastapopoulos · Février 8, 2010, 12:40

Le 08/02/2010 10:22, Joseph a écrit :

Si on passe la valeur 'off' au paramètre xx, est-ce que
[(#ENV{xx}|non)...] fonctionne ? Dans ce cas, y a-t-il un inconvénient à
stocker dans xx la valeur 'off' plutôt que '' ?

Non justement c'est ce que dit Matthieu : false c'est du vide ou bien "0". Tout autre valeur vaut true pour les filtres |oui et |non. Et du coup "off" ça oblige à faire un test supplémentaire |=={off}|oui.

--
RastaPopoulos

Jonathan · Février 8, 2010, 1:27

Jacques J. a écrit :

Cela ne ce passe-t-il pas pas dans le fichier cfg/saisies/oui_non.html ?
<code>
<input type="radio" name="#ENV{nom}" class="radio"
id='champ_#ENV{nom}_non'[ (#ENV{valeur}|non)checked='checked']
value='' />
</code>

La voilà l'idée que je n'ai pas eu... merci Jacques !

Les autres possibilités évoquées ne me semblent finalement pas aussi simple que celle ci : remplacer les checkboxes par des boutons radios, puisque comme le remarque RealET, c'est le HTML qui le veut.

Jonathan · Février 8, 2010, 1:34

RealET a écrit :

Tu peux utiliser le 2e paramètre de #CONFIG qui indique la valeur par défaut si ça renvoie rien :
[(#CONFIG{prefixe/bla,on}|=={on}|oui) ce que tu veux ]

Comme ça, ton plugin aura un comportement par défaut identique aux default= du fond de config ce qui fera que non configuré aura un comportement identique à configuré par défaut.

Oui... en théorie ça me paraît vrai. Non pas que je mette en cause tes paroles, mais j'ai besoin de tester pour être sur d'être d'accord avec toi.

Le problème que j'avais rencontré avec l'utilisation de la valeur par défaut est le même que celui évoqué au dessus. Il y a deux raisons possible pour que cela ne renvoie rien : CFG absent et case décochée. Dans ces deux cas la valeur par défaut remplace le vide, et donc je suis pareillement incapable de distinguer les deux situations.

Jonathan · Février 8, 2010, 1:38

Matthieu Marcillaud a écrit :

Dans le cadre de CFG, qui n'a en fait rien à voir avec saisies, il s'agit là d'attribuer une valeur par défaut à une configuration, avant que le formulaire de configuration ait été soumis. C'est un problème courant avec CFG. La solution qu'on utilise assez fréquemment est de créer les valeur par défaut de configuration à l'installation du plugin, via la fonction ecrire_config() par exemple, ou ecrire_meta() dans le cas ou le plugin peut ne pas dépendre de cfg.

ecrire_config('monplugin', array(
    'couleurs' => array(
        'base' => 'ffffff',
        'police' => '000000',
    ),
    ));

ecrire_meta('monplugin', serialize(array(
    'couleurs' => array(
        'base' => 'ffffff',
        'police' => '000000',
    ),
    )));

Ça c'est une astuce qui me plaît beaucoup ! Merci aussi !

Pour cette fois-ci, utiliser des boutons radios à la place de checkboxes a directement résolu le problème... mais je me suis en effet posé la question de la création d'une configuration à l'installation.

Peut-être ça vaudrait d'inclure cette astuce dans programmer.spip.org ?

rastapopoulos · Février 8, 2010, 1:59

Le 08/02/2010 14:34, Jonathan a écrit :

Le problème que j'avais rencontré avec l'utilisation de la valeur par
défaut est le même que celui évoqué au dessus. Il y a deux raisons
possible pour que cela ne renvoie rien : CFG absent et case décochée.
Dans ces deux cas la valeur par défaut remplace le vide, et donc je suis
pareillement incapable de distinguer les deux situations.

Ça ne renvoie pas la même valeur : une valeur nulle est interprétée comme "false". Mais pas réciproquement. La chaine vide ne sera pas nulle, elle sera juste "false".

Autrement dit, seul le cas où il y a vraiment pas de valeur fera que le test "|is_null" sera vrai. Dans tous les cas t'es bien obligé de faire un test supplémentaire puisque tu as trois cas : coché / pas coché / sans valeur.

--
RastaPopoulos

Jonathan · Février 8, 2010, 2:31

RastaPopoulos a écrit :

Ça ne renvoie pas la même valeur : une valeur nulle est interprétée comme "false". Mais pas réciproquement. La chaine vide ne sera pas nulle, elle sera juste "false".

Je vois...

Autrement dit, seul le cas où il y a vraiment pas de valeur fera que le test "|is_null" sera vrai. Dans tous les cas t'es bien obligé de faire un test supplémentaire puisque tu as trois cas : coché / pas coché / sans valeur.

Sauf que je cherchais à faire le test : si la case checkbox est décochée je n'affiche rien, dans toutes les autres situations j'affiche "truc" (sachant qu'en valeur par défaut il me fallait une checkbox cochée).

... j'ai peur de ne pas saisir toutes les implications de ce que tu m'expliques. Il faudra que je re-teste tout ça à tête reposée !

Merci à toi en tout cas pour les précisions !

larmarange · Février 8, 2010, 2:39

Le 08/02/2010 13:59, RastaPopoulos a écrit :

Le 08/02/2010 14:34, Jonathan a écrit :

Le problème que j'avais rencontré avec l'utilisation de la valeur par
défaut est le même que celui évoqué au dessus. Il y a deux raisons
possible pour que cela ne renvoie rien : CFG absent et case décochée.
Dans ces deux cas la valeur par défaut remplace le vide, et donc je suis
pareillement incapable de distinguer les deux situations.

Ça ne renvoie pas la même valeur : une valeur nulle est interprétée
comme "false". Mais pas réciproquement. La chaine vide ne sera pas
nulle, elle sera juste "false".

Autrement dit, seul le cas où il y a vraiment pas de valeur fera que le
test "|is_null" sera vrai. Dans tous les cas t'es bien obligé de faire
un test supplémentaire puisque tu as trois cas : coché / pas coché /
sans valeur.

Pour info, petit test en inclusion
Voici le test suivant :

Un fichier test.html :

TEST <p />

[(#ENV{varon}|oui) varon oui]
[(#ENV{varon}|non) varon non]
[(#ENV{varon}|is_null|oui) varon is_null]
<br />
[(#ENV{varvide}|oui) varvide oui]
[(#ENV{varvide}|non) varvide non]
[(#ENV{varvide}|is_null|oui) varvide is_null]
<br />
[(#ENV{varabs}|oui) varabs oui]
[(#ENV{varabs}|non) varabs non]
[(#ENV{varabs}|is_null|oui) varabs is_null]

Une inclusions dans un squelette parent :
<INCLURE{fond=test}{varon='on'}{varvide=''} />

Le résultat :
TEST

varon oui
varvide non
varabs non varabs is_null