Carnet Wiki

Doc Saisies complémentaire

SPIP-Contrib :: Carnet Wiki :: Recherche :

Doc Saisies complémentaire

Quelques annotations complémentaires à l’usage des Saisies avec leur Référence des saisies.

Voir aussi
-  les documentations de Vérifier avec sa Références des vérifications
-  Saisies : faire son marché qui contient notamment une liste de sélecteurs introduits par SPIP-Bonux : selecteur générique, selecteurs_article, selecteur_document, selection, selection_par_groupe, etc.
-  Hmmm il faut regarder aussi Sélecteur générique

-  Passage de tableaux en paramètres sous forme de chaine
-  Exemples de création de boutons radio et de menus select coucou
-  Saisie selection_multiple : écriture/Lecture de sélections multiples en base de données
-  Autres saisies
-  CSS : mettre 2 saisies côte-à-côte
-  Utilisation de tableaux php ou yaml
-  Vérifications de la conformité des valeurs saisies
-  Saisies « autonomes »
-  Affichage conditionnel de saisies
-  Génération automatique de CVT
-  Valeur prédéfinie forcée sur un input
-  Saisie d’un point sur une carte (map)
-  Personnaliser les valeurs pour Oui et Non pour les saisies ’cases’ et ’oui_non’
-  Quelques mystéres des saisies
-  Générer les saisies avec une boucle
-  Générer des saisies automatiquement à partir des champs extra
-  CSS selon choix boutons radios
-  Avenir de la saisie oui_non
-  Restreindre la saisie d’une date
-  Saisie « liste »
-  Appeler #GENERER_SAISIES sur des saisies définies par squelette
-  ’valeur_uniquement’ dans l’url et constante _SAISIES_AFFICHAGE_COMPACT
-  Exemple de formulaire formidalble avec des saisies et afficher_si
-  Saisie oui_non obligatoire


Passage de tableaux en paramètres sous forme de chaine

Certains paramètres de diverses saisies peuvent recevoir un tableau en paramètre :
-  datas= pour les selection, radio, checkbox, selection_multiple, et même les input en html5. (ce pourrait ou devrait peut être aussi l’être pour secteur mais ça n’est pas le cas).
-  defaut= pour les selection_multiple et les checkbox.

Ces paramètres ont donc pour valeur soit un texte sous la forme d’une chaine simple, soit un tableau de plusieurs valeurs. Pour passer un tableau de plusieurs valeurs, on peut passer un #ARRAY directement, ou une #LISTE ou bien alors une chaine servant à représenter un tableau, sous le format d’un raccourci de tableau spip ou sous le format simplifié d’une suite de lignes contenant les couples clé valeur séparés par un pipe (sans les pipe au début et à la fin de la ligne) :

|cle1|valeur1|
|cle2|valeur2|
cle3|valeur3
cle4|valeur4
valeur5
valeur6

Pour la saisie sélection, on peut avoir des sous-groupes, correspondant à la balise optgroup en HTML.
Un sous-groupe commence par une ligne sous la forme *Label. Il finit par un autre sous groupe, ou bien par /*.

*Sousgroupe1
|cle1|valeur1|
|cle2|valeur2|
*Sousgroupe2
cle3|valeur3
cle4|valeur4
/*
valeur5
valeur6

Boutons radios et Sélections

La doc n’indique pas comment créer les options des select ou les différents boutons radio d’un ensemble [1], mais le log ainsi que les fichiers sources donnent des exemples :

Pour les saisies "boutons radio"

[(#SAISIE{radio, afficher_liste,
        label=<:plugin:afficher_liste:>,
        explication=<:plugin:explication_afficher_liste:>,
        datas=#ARRAY{
                cle1,valeur1,
                cle2,valeur2,
                cle3,valeur3}
})]


[(#SAISIE{radio, maintenance}
        {label=Durée de maintenance}
        {defaut=12}
        {datas=#ARRAY{
                12, 12 mois,
                24, 24 mois,
                36, 36 mois}
        }
)]

Pour les saisies "select"

  1. [(#SAISIE{selection, maintenance}
  2. {label=Durée de maintenance}
  3. {option_intro=Sélectionnez la durée de maintenance}
  4. {defaut=12}
  5. {datas=#ARRAY{
  6. 12, 12 mois,
  7. 24, 24 mois,
  8. 36, 36 mois}
  9. }
  10. )]

Télécharger

Avec des sous-groupe :

  1. [(#SAISIE{selection, maintenance}
  2. {label=Durée de maintenance}
  3. {option_intro=Sélectionnez la durée de maintenance}
  4. {defaut=12}
  5. {datas=#ARRAY{
  6. mois,#ARRAY{
  7. 12, 12 mois,
  8. 24, 24 mois,
  9. 36, 36 mois},
  10. annee,#ARRAY{
  11. 12a, 12 ans,
  12. 24a, 24 ans
  13. }
  14. }}
  15. )]

Télécharger


Saisie selection_multiple : écriture/Lecture de sélections multiples en base de données

(attention : solution testée, mais est-ce la meilleure ? à confirmer par un expert !)

Avec selection_multiple, on ne peut enregistrer directement la valeur du champ dans la base de données. Voici une façon de faire utilisant la sérialisation de l’array représentant la sélection. Dans la base de données, le champ sera de type chaine de caractères, par exemple VARCHAR(62).

Supposons que l’on ait un formulaire editer_entreprise html avec la saisie suivante :

  1. [(#SAISIE{selection_multiple, annuaire, obligatoire=oui,
  2. label=<:entreprise:champ_annuaire_label:>,
  3. explication=<:entreprise:champ_annuaire_explication:>,
  4. datas=[(#ARRAY{1,Nogentech,2,FrenchTech,3,CCIHM})]})]

Télécharger

Dans editer_entreprise.php, les fonctions traiter et charger devront comporter la sérialisation et la désérialisation de l’array représentant les sélections dans le champ annuaire :

  1. function formulaires_editer_entreprise_charger_dist($id_entreprise = 'new', $retour = '', $associer_objet = '', $lier_trad = 0, $config_fonc = '', $row = array(), $hidden = '') {
  2. $valeurs = formulaires_editer_objet_charger('entreprise', $id_entreprise, '', $lier_trad, $retour, $config_fonc, $row, $hidden);
  3.  
  4. // désérialiser la valeur du champ annuaire :
  5. $valeurs['annuaire'] = unserialize($valeurs['annuaire']);
  6.  
  7. return $valeurs;
  8. }
  9.  
  10. function formulaires_editer_entreprise_traiter_dist($id_entreprise = 'new', $retour = '', $associer_objet = '', $lier_trad = 0, $config_fonc = '', $row = array(), $hidden = '') {
  11.  
  12. // sérialiser la valeur du champ annuaire :
  13. set_request('annuaire', serialize(_request('annuaire')));
  14.  
  15. $retours = formulaires_editer_objet_traiter('entreprise', $id_entreprise, '', $lier_trad, $retour, $config_fonc, $row, $hidden);
  16.  
  17. ...
  18.  
  19. return $retours;
  20. }

Télécharger


Autres saisies

Il y a moultes saisies dans le plugin, fort utiles dans certains cas, bien que non listées dans la documentation de référence :

Il faut regarder le contenu du sous-répertoire saisies et y faire son marché !

Certains font appel aux « selecteurs » définis dans SPIP Bonux et font un ample usage d’ajax pour faciliter la sélection, par navigation arborescente dans les rubriques par exemple.


CSS : mettre 2 saisies côte-à-côte

Par défaut, des #SAISIES successives sont affichées les unes sous les autres. (propriété clear:both; sur les <li> définie dans habillage.css).

Pour faire apparaître une saisie à droite d’une autre, sur la même ligne, il faut surcharger les propriétés CSS de manière à corriger les valeurs définies dans habillage.css

Pour cela on créera un fichier perso.css dans le dossier squelettes (si ce fichier n’existe pas déjà), qui contiendra les nouvelles valeurs.

Par exemple, pour un formulaire « identite » qui comporte une #saisie{input, prenom} immédiatement suivi d’une #saisie{input, nom}, pour que le nom apparaisse à droite du prénom, il suffit de mettre dans perso.css :

.formulaire_identite .editer {
       float: left;
}
.formulaire_identite  .editer_prenom {
       clear: left;
}
.formulaire_identite  .editer_nom {
       clear: right;
       margin-left: 10px;
}

L’affichage des erreurs n’est alors pas très agréable puisqu’en s’intercalant entre le label et la saisie, les erreurs rompent l’alignement horizontal des deux zones de saisie voisines.
Pour remédier, on peut :


Utilisation de tableaux php ou yaml

Les #SAISIES peuvent bien évidement être utilisées dans le cadre d’un formulaire CVT.

La documentation du plugin Saisies nous parle de tableaux PHP, mais ne nous dit pas clairement comment les récupérer dans une balise de #FORMULAIRE au sein d’un squelette. La réponse est, encore une fois, dans le fonctionnement de base des formulaires CVT : on définit le tableau dans la fonction "charger", on l’inclut dans le résultat renvoyé par la fonction, et il sera alors disponible dans l’environnement.

Exemple :
Dans un fichier formulaires/x.php :

formulaire_x_charger() {
  $valeurs = array();
  $saisie_age = array(
        'saisie' => 'input',
        'options' => array(
                'nom' => 'age',
                'label' => 'Votre age',
                'size' => 2)
   );
  $valeurs['saisie_age'] = $saisie_age;
  ...
  return $valeurs;

On récupère alors ces infos dans le squelette x.html du formulaire :
#SAISIES{#ENV{saisie_age}}

Comme indiqué dans Saisies, on pourra aussi rassembler toutes les saisies dans un tableau $formulaire = array ($saisie_age, ...);, et utiliser une balise #GENERER_SAISIES

Si l’on veut utiliser yaml pour définir une saisie (ce qui nous permettra de simplifier l’écriture et de séparer le code des données et de structure du formulaire), c’est aussi dans la fonction charger() que ca se passe :

function formulaires_y_charger_dist() {
       $valeurs = array();
       include_spip('inc/yaml');
       $saisie_age_yaml = find_in_path('saisie_age.yaml');
       $valeurs['encuesta'] = yaml_decode_file($saisie_age_yaml);
  ...
  return $valeurs;

Pour obtenir le même résultat, le ficher saisie_age.yaml doit contenir :

 saisie: 'input'
 options:
   nom: 'age'
   label: 'Votre age'
   size: 2

Vérifications de la conformité des valeurs

Restant dans le cadre d’une #SAISIES dans un formulaire CVT, la partie ’verifier’ du code associé fera les vérifications adéquates. Elle peut pour cela faire appel aux vérifications prédéfinies par le plugin ’verifier’ (actuellement encore en dev).

Par exemple, pour vérifier un code postal français, ça s’utilise en faisant :

       
$verifier = charger_fonction('verifier','inc');
if ($err=$verifier(_request('cp'), 'entier',  array('min'=>1000, 'max'=>99999))
    $erreurs['cp'] =  $err;

SAISIES propose également une fonction saisies_verifier($formulaire) qui vérifie et valide en un seul appel la conformité de toutes les saisies, et renvoie le tableau des erreurs dans le cas d’une non validité.

Pour cela,

Ce tableau contient 2 entrées :
-  ’type’
-  ’options’

Pour chaque saisie, saisies_verifier vérifie si elle a bien été saisie (dans le cas d’une saisie obligatoire), puis appelle la fonction de vérification avec les options indiquées.

Reprenant le même exemple que ci-dessus, on ajoute des options de vérification :

formulaire_x_charger() {
  $valeurs = array();
  $saisie_age = array(
        'saisie' => 'input',
        'options' => array(
                'nom' => 'age',
                'label' => 'Votre age',
                'size' => 2),
        'verifier' => array (type, entier,
                options => array (max=>0, min=>100)));
  $valeurs['saisie_age'] = $saisie_age;
  ...
  return $valeurs;

Si l’on passe en yaml, le ficher saisie_age.yaml devient :

 saisie: 'input'
 options:
   nom: 'age'
   label: 'Votre age'
   size: 2
 verifier:
   type: 'entier'
   options:
     min: 0
     max: 100

Saisies autonomes ou non autonomes

Le code html servant à générer chaque saisie est défini par les squelettes contenus dans le répertoire saisies du plugin. Ces squelettes sont inclus par le squelette générique _base.html, qui teste si la saisie à afficher est "autonome".

La plupart des saisies ne sont pas autonomes, et en plus de l’inclusion, les traitements génériques aux saisies sont effectués (en dehors donc du fichier propre à la saisie, qui ne présente que les spécificités de la saisie) :
-  l’affichage d’une erreur associée si il y en a une,
-  le label,
-  les explications,
-  les ’attention’ et les traitements de obligatoire...

Les saisies autonomes sont par contre inclues sans rien d’autre autour. Elles sont dites "autonomes" car c’est leur propre squelette qui gère, ou non, l’affichage des labels, erreurs, explications, attentions et obligatoire. Si le squelette qui définit une saisie autonome n’affiche ni erreur ni label, il n’y aura donc pas d’affichage des erreurs ni des labels.

Les saisies qui sont autonomes sont définies par la fonction saisies_autonomes qui appelle le pipeline du même nom qui permet d’en ajouter de nouvelles. Ce sont par défaut les saisies :
-  fieldset
-  hidden
-  destinataires
-  explication

On peut modifier cette liste en redéfinissant le pipeline éponyme. Ou bien (mauvaise pratique) son unique usage : en créant dans le répertoire squelette/saisies une surcharge de _base.html :
à la place de #SET{saisies_autonomes,#VAL|saisies_autonomes}
mettre #SET{saisies_autonomes,#ARRAY{fieldset, hidden, destinataires, explication, cequonveutenplus}}


Affichage conditionnel de saisies : l’option ’afficher_si’

L’option afficher_si ajoutée à une saisie permet de préciser une condition sur les autres valeurs d’un formulaire indiquant si la saisie doit être affichée ou non.

L’option afficher_si n’a d’effet que sur un appel PHP ou sur les balises #GENERER_SAISIES et #VOIR_SAISIES (et pas avec #SAISIE). Les conditions doivent porter sur des champs définis dans le tableau de saisies.

Il est ainsi possible d’insérer - ou plutôt de simuler- plusieurs formulaires avec dans une même page.

Cette option est par exemple utilisée par certaines noisettes aveline dans l’epace privé.

Exemple YAML :

  1. -
  2.   saisie: 'radio'
  3.   options:
  4.   nom: 'oui_non'
  5.   label: 'Utilisez-vous SPIP ?'
  6. -
  7.   saisie: 'input'
  8.   options:
  9.   nom: 'raison_non'
  10.   label: 'Si non, pourquoi ?'
  11.   afficher_si: '@choix@ == ""'
  12. -
  13.   saisie: 'input'
  14.   options:
  15.   nom: 'raison_oui'
  16.   label: 'Si oui, pourquoi ?'
  17.   afficher_si: '@choix@ == "on"'

Télécharger

Le nom des champs doit être encadré par le caractère @.

-  Attention : si vous utilisez un formulaire CVT, il est important que le nom de la variable contenant le tableau de saisie commence par _ (underscore) afin de désactiver traitements automatiques de SPIP (cf. http://www.spip.net/fr_article4151.html). Sinon, par exemple, les guillements seront transformés en entitées HTLM.

-  Il est possible d’utiliser des parenthèses dans les conditions ainsi que les opérateurs && et ||.

Par exemple : afficher_si: '@radio1@ == "on" || (@input2@ != "" && @select3@=="valeur3")'

-  A partir de la version 1.9.3 de saisies, on peut également vérifier la présence d’un plugin pour l’affichage conditionnel d’une saisie avec @plugin:prefixe_du_plugin@.

-  A partir de la version 1.9.7 de saisies, on peut également tester la valeur d’un champ meta de configuration de plugin pour l’affichage conditionnel d’une saisie avec @config:prefixe_plugin:meta_a_tester@ test à effectuer. Ex : afficher_si: '@config:mon_plugin:afficher_un_truc@ == "on"'

Vérifier et traiter avec afficher_si (à partir de la version 1.23.0)

Si on utilise la fonction saisies_verifier pour vérifier les saisies (voir plus haut) ou la génération automatique de formulaire CVT (voir ci-après), alors les saisies masquées par afficher_si ne seront pas vérifiées. Quelle que soit leur valeur, cette dernière sera transformée en NULL et cette valeur nulle sera transmise à la fonction traiter.

Si pour une raison ou une autre on a besoin de récupérer malgré tout la valeur des saisies masquées, on peut appeler, dans la fonction traiter, saisies_verifier en lui passant FALSE en deuxième paramètre. Dès lors, les saisies masquées seront vérifiées selon les options de vérification transmises, qu’elles soient masquées ou non, et leur valeur sera transmise à la fonction traiter. Ce sera donc cette dernière qui sera chargée, le cas échéant, de tenir compte ou non du caractère masqué de ces saisies.

Option "afficher_si_remplissage"

L’affichage lors de la saisie est conditionné par la satisfaction de la condition indiquée, mais l’affichage des résultats finaux n’est pas conditionné et la saisie y figure toujours, quelle que soit la satisfaction de la condition indiquée.

Le fonctionnement est donc identique à afficher_si lors de la saisie seulement, et il n’y a aucun effet lors de la vue (avec #VOIR_SAISIES) alors que le conditionnement de l’affichage par afficher_si prend effet pour aussi sur la vue.


Génération automatique de formulaire CVT : formulaires_moncvt_saisies

Nouvelle fonctionnnalité dans Saisies : la génération automatique d’un formulaire CVT uniquement à partir de la déclaration d’une liste de saisies. (commit autodocumenté)

Une nouvelle fonction s’ajoute donc à l’API des CVT :
function formulaires_moncvt_saisies()
(ou function formulaires_moncvt_saisies_dist())

Elle doit retourner un tableau PHP selon le formalisme de l’API de Saisies.

Si cette fonction existe, alors Saisies
-  va automatiquement déclarer dans charger() les champs retournés par le tableau PHP, en les ajoutant dans une variable _saisies
-  va automatiquement regarder les erreurs dans verifier()
-  et va automatiquement générer le HTML du formulaire SI le fichier formulaires/moncvt.html est VIDE (mais existant !). Si on préfère, on peut toujours faire le formulaire soi-même et utiliser #ENV{_saisies}.

Rq : C’est une contrainte actuelle du système CVT : un formulaire a l’obligation pour exister d’avoir un fichier HTML en dur, même vide, sinon SPIP retourne du vide. Il n’y a donc pas pour le moment de moyen d’éviter la création de ce fichier, même vide.

Evidement, la fonction traiter() est du ressort de chacun.

Exemple

On peut s’en servir notamment pour la création d’un formulaire de configuration. Il suffit de définir la fonction formulaires_truc_saisies_dist($params) dans le ficher PHP de définition du formulaire. Cela permet de déclarer toutes les zones de saisies avec en même temps leurs critères de validité et de vérification (API verifier). Dans ce cas, le fichier html doit exister, mais être vide.

Par exemple, pour le plugin ’produits’ le fichier formulaires/configurer_produits.php :

  1. <?php
  2. if (!defined('_ECRIRE_INC_VERSION')) return; // Sécurité
  3.  
  4. function formulaires_configurer_produits_saisies_dist(){
  5. include_spip('inc/config');
  6. return array(
  7. 'saisie' => 'input',
  8. 'options' => array(
  9. 'nom' => 'taxe',
  10. 'label' => _T('produits:configurer_taxe_defaut_label'),
  11. 'defaut' => lire_config('produits/taxe', 0),
  12. ),
  13. 'verifier' => array(
  14. 'type' => 'decimal'
  15. )
  16. )
  17. );
  18. }
  19. ?>

Télécharger

Autres exemples

-  Sur : ?page=saisies_cvt (avec Z). Et le code dans formulaires/saisies_cvt.php.

-  Autre exemple : http://zone.spip.org/trac/spip-zone/browser/_plugins_/produits/formulaires/editer_produit.php

-  Sur http://zone.spip.org/trac/spip-zone/changeset/70506


Forcer une valeur sur une saisie ’input’

On peut définir des valeurs de configuration prioritaires en se servant de defines PHP... Ces valeurs prennent le pas sur la configuration SPIP (via cfg, bonux ou SPIP3). Cela permet de forcer une valeur par rapport à celle du contexte.

Log : http://zone.spip.org/trac/spip-zone/changeset/50402

Exemple d’utilisation dans le plugin "tickets" : http://zone.spip.org/trac/spip-zone/browser/_plugins_/tickets/formulaires/config_tickets_general.html?rev=50403#L16

  1. #SET{readonly,''}
  2. [(#VAL{_TICKETS_LISTE_VERSIONS}|defined|?#SET{versions_readonly,readonly},#SET{versions_readonly,''}})]
  3. [(#GET{versions_readonly}|?{#SET{explications_versions,<:tickets:cfg_explication_readonly:>},#SET{explications_versions,<:tickets:cfg_explication_versions:>}})]
  4. [(#SAISIE{input, versions,
  5. label=<:tickets:cfg_lbl_versions:>,
  6. readonly=#GET{versions_readonly},
  7. explication=#GET{explications_versions},
  8. valeur_forcee=[(#GET{versions_readonly}|?{#EVAL{'_TICKETS_LISTE_VERSIONS'},''})]})]

Télécharger

Cette partie du code teste si _TICKETS_LISTE_VERSIONS est défini,
et dans ce cas :

— Mais pourquoi ce nouveau paramètre "valeur_forcee" ne serait que sur les inputs ?
— Parce que je n’ai pas eu le temps et je n’ai pas le code pour tester sur les autres...


Saisie d’un point sur une carte (googlemap ou autre)

Le plugin GIS définit une nouvelle #SAISIE : une carte cliquable, qui ne constitue pas à proprement parler un champ, mais qui sait pré-remplir d’autres champs qu’on lui passe en paramètre (définis par défaut donc on peut s’en passer) : lat, lon, adresse, code_postal, ville, region, pays.

Pour en bénéficier il faut donc activer le plugin GIS (commit : http://zone.spip.org/trac/spip-zone/changeset/53606)

Exemple d’utilisation ?
non mais


Personnaliser les valeurs Oui et Non pour les saisies oui_non et les cases

57042 (puis 94737 pour les .yaml des cases) introduisent 2 nouveaux champs transmissibles dans l’env. Ces champs définissent la valeur renvoyée par la saisie en cas de saisie de Oui ou de Non :
-  valeur_oui (par défaut : ’on’)
-  valeur_non (par défaut : ’’ chaine vide)


attributs mystères

Trouvé dans les yaml du plugin formidable :
-  env : true


Générer des saisies au moyen d’une boucle

Dans certains cas, on peut avoir besoin de générer des saisies au moyen d’une boucle, afin de simplifier un peu plus l’écriture d’un squelette par exemple. Il faut alors utiliser la syntaxe #SAISIE* (avec étoile simple) afin d’empêcher les traitements de Spip.

Exemple avec une boucle DATA (Spip 2.* + plugin itérateurs ou Spip 3) :

La boucle DATA permet de manipuler des listes, dont on peut se servir pour générer une suite de saisies :

  1. <B_saisies>
  2. Etes-vous amateur des fromages suivants ?
  3. <BOUCLE_saisies(DATA){liste camembert,mimolette,roquefort,cheddar}>
  4. #SAISIE*{oui_non, #VALEUR, label=#VALEUR}
  5. </BOUCLE_saisies>

Télécharger

(note : pour personnaliser le label, on utilisera plutôt un tableau avec #CLE et #VALEUR, cf. boucle DATA)

Exemple sur une table existante : spip_grappes

  1. #SET{tableau_grappe, #ARRAY}
  2. <BOUCLE_selection_grappe(GRAPPES){...}>
  3. #SET{tableau_grappe,#GET{tableau_grappe}|array_merge{#ARRAY{#TITRE,#ID_GRAPPE}}}
  4. </BOUCLE_selection_grappe>
  5. [(#SAISIE*{selection, nom_saisie}
  6. {label=Sélectionnez une grappe}
  7. {datas=#GET{tableau_grappe}|array_flip})]

Télécharger

(note : ici on inverse index (#ID_GRAPPE) et valeur (#TITRE) lors de la création du tableau car les tableaux associatifs ne peuvent pas avoir des valeurs numériques en index. Il suffit dans SAISIE de le retourner "|array_flip" afin de l’avoir sous la forme plus habituelle de couples id1,valeur1.


Générer des saisies automatiquement à partir des champs extra

Exemple : champs extra sur spip_articles

  1. <BOUCLE_champs_extra(DATA){source table,#CONFIG*{champs_extras_spip_articles}|unserialize }>
  2. [(#SAISIE{[(#VALEUR|table_valeur{saisie}|print_r{1})],[(#VALEUR|table_valeur{options}|table_valeur{nom}|print_r{1})]}
  3. {label=[(#VALEUR|table_valeur{options}|table_valeur{label}|print_r{1})]}
  4. {datas=[(#VALEUR|table_valeur{options}|table_valeur{datas})]}
  5. )]
  6. </BOUCLE_champs_extra>

Télécharger


CSS selon choix boutons radios

Un formulaire de choix par bouton radio, dont les valeurs de choix sont

4|Très satisfait
3|Plutôt satisfait
2|Plutôt pas satisfait
1|Pas du tout satisfait

donne :

<div class="choix choix_4">
 <input id="champ_radio_2_1" class="radio" type="radio" value="4" name="radio_2">
 <label for="champ_radio_2_1"> Très satisfait</label>
</div>

<div class="choix choix_3">
 <input id="champ_radio_2_2" class="radio" type="radio" value="3" checked="checked" name="radio_2">
 <label for="champ_radio_2_2"> Plutôt satisfait</label>
</div>

<div>...

Pour que le bouton activé prenne une couleur différente selon le choix, on peut utiliser la pseudo-classe :checked sur input (et NON input[checked=checked] ) :

div.choix_4 input[type=radio]:checked + label {    background-color: #0f0; }

div.choix_3 input[type=radio]:checked + label {    background-color: #00f; }

div.choix_2 input[type=radio]:checked + label {    background-color: #f90; }

div.choix_1 input[type=radio]:checked + label { background-color: #f00; }

Ainsi quand je coche un bouton radio, son label passe dans la couleur correspondante, mettant ainsi en valeur l’impression générale des saisies.

(Voir http://www.thecssninja.com/css/custom-inputs-using-css)


Avenir de la saisie oui_non

Rasta exprime son avis :

La saisie oui_non reste là de manière historique, mais ergonomiquement et accessiblement, elle devrait être remplacée
-  soit par une case unique à cocher (pas coché = non, coché = oui),
-  soit par deux boutons radios dont les labels sont beaucoup plus explicites (cela dit on peut changer label_oui et label_non normalement, mais ce n’est pas incitatif).

Idée : faire disparaitre des choix mais sans casser l’existant (enlever le yaml en laissant le squelette ?) ou alors rendre obligatoire la définition d’un label pour le oui et le non, plutôt que de mettre juste "oui" et "non" (cela revient à un cas particulier de la saisie boutons radios mais avec un choix binaire).


Restreindre une date

Il est possible de restreindre les dates affichées et ne pas afficher une date antérieure à la date du jour, depuis la révision 21482 , au moyen de l’option « attributs » avec dedans une valeur ’data-yearRange="lacontrainte"’. Voir la doc de l’option-yearRange pour la syntaxe détaillée.

  1. [(#SAISIE{date,date_naissance,
  2. attributs='data-yearRange="c-80:c+0"',
  3. label=Date de naissance})]

Télécharger


Autre type de saisie : liste

Cette saisie est implémentée par un autre plugin : saisie_liste, qu’il faut installer en plus de ’saisie’.

Voir la doc complète et à jour

Cette saisie permet de gérer des listes.
On peut par exemple s’en servir pour demander à l’utilisateur de saisir une liste de personnes ou d’événements.

On commence par passer en paramètre une liste de saisies qui définissent alors chacun des éléments de la liste.
La saisie générée permet ensuite à l’utilisateur d’éditer, de créer ou de supprimer des éléments de cette liste et/ou de modifier leur ordre.

Elle peut fonctionner sans javascript, mais pour les utilisateurs qui l’activent, on peut réordonner les éléments par glisser-déposer via le plugin jqueryui.sortable.

Un fois le plugin installé, on peut voir des exemples d’utilisation de la saisie sur la page `/ecrire/ ?exec=exemples_saisie_liste`.

Appel de la saisie

La saisie s’appelle dans les squelettes comme n’importe quelle saisie.

  1. [(#SAISIE{liste, ma-liste,
  2. label=Objets,
  3. saisies=#ARRAY{0, #ARRAY{saisie, input,
  4. label, Titre de l'objet,
  5. nom, titre_objet},
  6. 1, #ARRAY{saisie, textarea,
  7. nom, description,
  8. label, Description}}
  9. })]

Télécharger

On peut aussi utiliser le format de la balise `#GENERER_SAISIES`

  1. $ma_saisie = array(
  2. 'saisie' => 'liste',
  3. 'options' => array(
  4. 'nom' => 'ma-liste',
  5. 'label' => 'Objets',
  6. ),
  7. 'saisies' => array(
  8. 'saisie' => 'input',
  9. 'options' => array(
  10. 'label' => "Titre de l'objet",
  11. 'nom' => 'titre_objet',
  12. ),
  13. ),
  14. 'saisie' => 'textarea',
  15. 'options' => array(
  16. 'label' => "Description",
  17. 'nom' => 'description',
  18. ),
  19. ),
  20. ),
  21. );

Télécharger

Paramètres :

-  nom => Le nom de la saisie. Obligatoire, le reste est
optionnel
-  label => Le label
-  legende => La légende du fieldset qui contient la liste
-  saisies => La liste de saisies définissant un élément
-  defaut => Le tableau des valeurs par défaut de la saisie
-  interdire_ajout => Interdit d’ajouter des éléments à la liste.
-  ordre_fixe => Interdit de réordonner les éléments de la liste
-  cacher_supprimer => Cache les boutons supprimer sur les éléments
de la liste
-  texte_bouton_ajouter => Le texte du bouton ajouter. "Ajouter" sinon.
-  texte_bouton_supprimer => Le texte du bouton supprimer
-  masquer_nouveaux => Ajoute un javascript qui masque le nouvel élément
de la liste jusqu’à ce qu’on clique sur "Ajouter".

Traitement des valeurs postées

Pour que la saisie puisse fonctionner correctement, il faut exécuter des traitements au début des fonctions `verifier` et `traiter`. Le plus simple est de toujours commencer vos fonctions `verifier` et `traiter` par :

  1. if (saisies_liste_verifier('ma-liste'))
  2. return array();

Télécharger

et vos fonctions traiter par :

  1. if (saisies_liste_traiter('ma-liste'))
  2. return array('editable' => 'oui');

Télécharger

où `ma-liste` est le nom de la saisie liste que vous avez créé.

Si le formulaire contient plusieurs saisies liste, il faut passer à ces fonctions un tableau des noms des saisies, par exemple :

  1. if (saisies_liste_verifier(array('liste-1', 'liste-2', 'liste-3')))
  2. return array();

Télécharger

Les fonctions `saisies_liste_verifier` et `saisies_liste_traiter` s’occupent de préparer les valeurs postées de manière à cacher celles qui ne sont utiles que pour le fonctionnement interne de la saisie. Utiliser la fonction `_request` avant des les avoir appelées est à vos risques et périls…

Elle retournent le nom de la saisie si le formulaire à été posté par un submit propre à une saisie liste, comme le bouton supprimer ou les flèches. Dans ce cas on souhaite en général interrompre les traitements du formulaire comme dans les exemples ci-dessus.

Dans le cas où le formulaire à été posté par un autre submit, `saisies_liste_verfier` et `saisies_liste_traiter` retournent `FALSE`. On peut alors récupérer les valeurs saisies en appelant :
_request('ma-liste');

qui aura la forme suivante (si on reprend l’exemple ci-dessus) :

  1. 0 => array(
  2. 'titre_objet' => "Le premier titre saisi par l'utilisateur",
  3. 'description' => "Une longue description de l'objet…",
  4. ),
  5. 1 => array(
  6. 'titre_objet' => "Le deuxième titre saisi par l'utilisateur",
  7. 'description' => "Une description du deuxième objet…",
  8. ),
  9. )

Télécharger

On peut évidement utiliser un tableau de ce genre pour pré-remplir la saisie dans la fonction charger, ou pour passer des valeurs par défaut à la saisie.

Personnalisation du glisser-déposer

Pour personnaliser l’appel au plugin jqueryui.sortable, on peut surcharger le squelette `javascript/saisie_liste.js.html` (voir le code de ce squelette pour plus d’informations).
On peut aussi créer un fichier `javascript/saisie_ma-liste.js.html` pour surcharger une saisie particulière.


utilisation de #GENERER SAISIES avec des saisies définies en squelette SPIP.

La doc est maigre a propos de #GENERER_SAISIES, mais le plugin ’saisies’ contient un dossier ’test’ avec divers fichiers dont un exemple d’utilisation de #GENERER SAISIES tout en squelette SPIP.

Voici un peu simplifié :

  1. <h2>Génération complète du contenu (l'intérieur) d'un formulaire</h2>
  2. #SET{saisies,
  3. #LISTE{
  4. #ARRAY{
  5. saisie, input,
  6. options, #ARRAY{
  7. nom, prenom,
  8. label, Prénom,
  9. }
  10. },
  11. #ARRAY{
  12. saisie, input,
  13. options, #ARRAY{
  14. nom, courriel,
  15. label, Courriel,
  16. obligatoire, oui
  17. },
  18. verifier, #ARRAY{
  19. type, email
  20. }
  21. },
  22. #ARRAY{
  23. saisie, case,
  24. options, #ARRAY{
  25. nom, case,
  26. label, Une sorte de case à cocher,
  27. label_case, Check la vibes
  28. }
  29. },
  30. #ARRAY{
  31. saisie, fieldset,
  32. options, #ARRAY{
  33. nom, adresse,
  34. label, Adresse
  35. },
  36. saisies, #LISTE{
  37. #ARRAY{
  38. saisie, textarea,
  39. options, #ARRAY{
  40. nom, voie,
  41. label, Voie,
  42. obligatoire, non,
  43. }
  44. },
  45. #ARRAY{
  46. saisie, input,
  47. options, #ARRAY{
  48. nom, code_postal,
  49. label, Code postal,
  50. obligatoire, oui
  51. }
  52. },
  53. #ARRAY{
  54. saisie, input,
  55. options, #ARRAY{
  56. nom, ville,
  57. label, Ville,
  58. obligatoire, oui
  59. }
  60. }
  61. }
  62. },
  63. #ARRAY{
  64. saisie, oui_non,
  65. options, #ARRAY{
  66. nom, peutetre,
  67. label, Tu veux ou tu veux pas ?,
  68. obligatoire, oui,
  69. info_obligatoire, " / obligatoire"
  70. }
  71. },
  72. }
  73. }
  74. <form class="formulaire_spip" action="#SELF" method="post">
  75. <ul>
  76. #GENERER_SAISIES{#GET{saisies}}
  77. <li class="boutons">
  78. <input type="submit" class="submit" />
  79. </li>
  80. </ul>
  81. </form>

Télécharger

arg ’valeur_uniquement’ dans l’url et constante _SAISIES_AFFICHAGE_COMPACT

À documenter
-  http://zone.spip.org/trac/spip-zone/changeset/99576]
-  http://zone.spip.org/trac/spip-zone/changeset/99551

Vague idée de ce que ça fait : En définissant la constante _SAISIES_AFFICHAGE_COMPACT dans le fichier d’option :
-  l’intitulé de la saisie et sa réponse se retrouvent sur la même ligne
-  l’affichage devient plus compact pour les checkboxes. Les réponses vides n’y figurent plus.

Exemple de formulaire formidable avec des saisies et afficher_si

id_formulaire: '1'
identifiant: test
titre: toto
descriptif: ''
css: ''
message_retour: ''
saisies:
 - { options: { label: 'Nombre de ruches', type: text, size: '40', autocomplete: defaut, nom: input_1 }, verifier: { type: entier, options: { min: '1', max: '5' } }, identifiant: '@58407d6f9dfbf', saisie: input }
 - { options: { label: 'Ruche 1', type: text, afficher_si: '@input_1@>0', size: '40', autocomplete: defaut, nom: input_2 }, identifiant: '@58407d90822f5', saisie: input }
 - { options: { label: 'Ruche 2', type: text, afficher_si: '@input_1@>1', size: '40', autocomplete: defaut, nom: input_3 }, identifiant: '@58407da42b1d3', saisie: input }
traitements:
 enregistrement: { multiple: on, modifiable: '', identification: cookie, anonymiser: '', anonymiser_variable: '', ip: on, moderation: posteriori, analyse_exclure_champs: '' }
public: non
apres: formulaire
unicite: ''
message_erreur_unicite: ''
url_redirect: ''
statut: prop
resume_reponse: ''
date_creation: '2016-12-01 20:43:20'
maj: '2016-12-01 20:47:50'

oui_non et saisie obligatoire

Q : Dans un formulaire formidable, je veux rendre obligatoire la saisie oui/non d’une réponse. Dans l’onglet "validation" j’ai donc coché "oui" pour obligatoire et mis un texte dans le message d’obligation. Mais si on répond "non" à l’enregistrement du formulaire on a le message : "Il y a des erreurs dans les champs ci-dessous, veuillez vérifier votre envoi." Si on répond "oui" on peut valider

A : Avec oui_non, le choix non renvoie une chaine vide, qui ne peut pas passer une validation "obligatoire".
Dans ce cas là, il faut passer par une saisie boutons radio avec les choix oui|Oui non|Non

Rq : la saisie oui_non est dépréciée. Peu accessible.

[1Pour les mettre en ligne : adapter <style>.choix {display:inline;}</style> !