Saisies

Published : 27 March 2010 – updated on 13 September 2021 – by Maïeul, RastaPopoulos – 670 commentaires

72 Votes

Le plugin Saisies facilite le développement des formulaires, en proposant des méthodes et outils pour déclarer et vérifier les champs.

Introduction

Créer un formulaire est une tâche toujours un peu répétitive : les champs ont souvent les mêmes propriétés, le même accompagnement (message d’erreur, explication ...) et la même structure HTML. Ce plugin est un outil d’aide au développement, ayant pour but de faciliter et d’accélérer l’écriture des formulaires.

Pour cela, Saisies propose plusieurs mécanismes (balises, API PHP) pour générer et manipuler plus facilement les champs des formulaires. De cette manière, les squelettes de formulaires sont :

plus lisibles : il n’y a que le strict nécessaire dedans, pas de répétition ;
intégrés au fonctionnement CVT de SPIP, notamment pour la gestion des erreurs sur les champs ;
automatiquement compatibles avec les recommandations HTML/CSS de SPIP.

Dans la présente documentation, nous présentons la manière de construire un formulaire avec Saisies de la méthode la plus robuste à la méthode la moins robuste.

Les méthodes moins robustes sont présentées pour deux raisons :

ce sont les méthodes les plus anciennes. On trouve encore beaucoup de code les utilisant.
il est parfois nécessaire de passer par là, pour des réglages fins.

Dans la présente documentation, lorsqu’un code est entre chevrons (comme <ceci>), vous devez le remplacer par une valeur correspondant à votre projet.

Cette documentation est valable à partir de la version 3.53.0 du plugin.

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Saisies augmente l’API CVT de SPIP avec une fonction formulaires_<nomduformulaire>_saisies() afin de déclarer l’ensemble des champs d’un formulaire et leur vérification dans une unique syntaxe. Cette fonction permet également de déclarer différents réglages de formulaire, tel que :

le label du bouton de validation final;
l’utilisation en multiétapes.

Grâce à ce mécanisme, pour les cas les plus courants, les fonctions formulaires_<nomduformulaire>_charger() et formulaires_<nomduformulaire>_verifier() deviennent facultatives. Saisies s’occupera de tout suivant votre déclaration. Seule la fonction formulaires_<nomduformulaire>_traiter() reste toujours de votre ressort.

De même, par défaut, vous n’avez plus à vous occuper du squelette. Il doit toujours être présent, avec le même nom que votre fichier PHP dans le dossier formulaires/, mais vous devez le laisser totalement vide. Saisies s’occupera de générer le HTML complet, en suivant les recommandations de structuration de SPIP.

Enfin, dans le cas particulier où vous créez un formulaire de configuration, vous n’aurez même pas à déclarer les valeurs par défaut ni le traitement. Voir l’article “Formulaire de configuration avec le plugin Saisies”.

Mise en œuvre

Il vous faut donc créer un fichier formulaires/<nomduformulaire>.html vide, ainsi qu’un fichier formulaires/<nomduformulaire>.php contenant deux fonctions :
- formulaires_<nomduformulaire>_traiter(), qui indique ce que votre formulaire doit effectuer comme traitement ; cela n’est pas du ressort du plugin Saisies;
- formulaires_<nomduformulaire>_saisies(), pour déclarer les saisies proprement dites.

Cette dernière fonction reçoit comme arguments les mêmes arguments que la fonction _charger() du formulaire CVT, et elle doit retourner un tableau PHP contenant la liste de toutes vos saisies suivant un formalisme attendu.

formulaires_<nomduformulaire>_saisies(…) {
    $saisies = array(…);
    return $saisies;
}

Déclaration de l’ensemble des saisies

Chaque ligne globale du tableau renvoyé décrit une saisie.
L’ordre des éléments sera l’ordre des saisies.

$saisies = array(
    array(…), // une saisie
    array(…), // une saisie
    array(…), // une saisie
);

Déclaration d’une saisie individuelle

Chaque saisie est elle-même décrite dans un tableau, qui prend par exemple la forme suivante :

array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'nom',
        'label' => 'Votre nom',
        'defaut' => 'Valeur par défaut'
    ),
);

On consultera “Référence des saisies” pour avoir l’ensemble des saisies et des options disponibles en standard.

D’autres plugins ajoutent leurs propres saisies, et vous pouvez aussi créer vos propres saisies.

Déclaration des saisies enfants

Les saisies qui acceptent des enfants (comme les fieldsets) les placent dans une clé saisies dont la valeur est un tableau ayant la même structure que le tableau global :

$un_fieldset = array(
    'saisie' => 'fieldset',
    'options' => array(
        'nom' => 'mon_groupe',
        'label' => 'Mon groupe de champ'
    ),
    'saisies' => array(
        array(…), // une autre saisie
        array(…), // une autre saisie
        array(…), // etc
    )
);

Appliquer une vérification

Pour des vérifications simples et uniques vous pouvez en déclarer une vérification à appliquer sur chacune de vos saisies, avec le plugin API de Vérification.

Il faut alors ajouter une clé verifier selon ce formalisme :

array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'nom',
        'label' => 'nom',
        'obligatoire' => 'oui',
    ),
    'verifier' => array(
        'type' => 'entier',
        'options' => array(
            'min' => 100,
            'max' => 500
        ),
    ),
);

Consulter “Références des vérifications” pour la liste des types de vérifications livrés avec le plugin et de leurs options.

Support du multilinguisme

Saisies supporte le multilinguisme. Ainsi, dans l’exemple ci-dessous, la chaine de langue <:cle:valeur:> sera automatiquement interprétée.

array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'nom',
        'label' => '<:cle:valeur:>',
        'size' => 50
    ),
);

Options globales

Il est possible de déclarer des options d’affichage globales à l’ensemble du formulaire. Elles sont alors placées dans une clé options à la racine du tableau des saisies.

$saisies = array(
    'options' => array(
        // Changer l'intitulé du bouton final de validation
        'texte_submit' => 'Valider c’est gagné',
        …
        '<option>' => '<valeur>' //Une autre option
    ),
    array(…), // une saisie
    array(…), // une saisie
    array(…), // une saisie
);

Option	Usage	Valeur possible	Valeur par défaut
Options pour le bouton de validation
`texte_submit`	Texte du bouton de validation	Texte, passe par `_T_ou_typo()`	`<:bouton_enregistrer:>`
`afficher_si_submit`	Condition pour afficher le bouton de validation	Voir “Affichage conditionnel des saisies : syntaxe des tests”	`null`
Options pour la gestion des étapes multiples
`etape_activer`	Activer la gestion multi-étapes, chaque `fieldset` de premier niveau devient une étape	`True\|False`	`False`
`etapes_presentation`	Mode de présentation des étapes en haut du formulaire	`'defaut'\|'current'`, il est possible de créer son propre mode en créant un squelette `formulaires/inc-saisies-cvt-etapes-<presentation>.html`	`defaut`
`etapes_suivant`	Texte du bouton pour aller à l’étape suivante	Texte, passe par `_T_ou_typo()`	`<:bouton_suivant:>`
`etapes_precedent`	Texte du bouton pour revenir à l’étape précédente	Texte, passe par `_T_ou_typo()`	`<:precedent\|ucfirst:>`
`etapes_ignorer_recapitulatif`	Permet de ne pas insérer de récapitulatif avant la validation finale	`True\|False`	`False`
Options techniques
`verifier_valeurs_acceptables`	Permet de s’assurer que les valeurs reçues figurent bien parmi les valeurs proposées lors de la saisie du formulaire	`True\|False`	`False`
`afficher_si_avec_post`	Permet que les saisies masquées par affichage conditionnel soient tout de même postées	`True\|False`	`False`
`inserer_debut`	Contenu arbitraire à insérer au début du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractères	`null`
`inserer_fin`	Contenu arbitraire à insérer à la fin du formulaire, par exemple pour appeler un script Javascript	Chaîne de caractère	`null`

Si un texte passe par _T_ou_typo(), cela peut être :

un texte directement écrit dans la langue du site;
un appel à une chaîne de langue sous la forme <:fichier_de_langue:chaine:>;
un texte utilisant la balise <multi> pour gérer l’internationalisation.

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Parfois il est nécessaire d’avoir des vérifications supplémentaires sur les saisies. Pour ce faire, vous devez déclarer votre propre fonction formulaires_<nomduformulaire>_verifier().

Dans ce cas, vous ne perdrez pas le bénéfice d’une déclaration des vérifications de base dans votre tableau de saisies : celles-ci sont alors automatiquement effectuées après vos propres vérifications.

Toutefois, il est parfois nécessaire de faire en sorte que les vérifications “par déclaration” se fassent avant vos propres vérifications. Dans ce cas, la méthode la plus propre est de déclarer ses vérifications non pas sous forme d’une fonction formulaires_<nomduformulaire>verifier(), mais par l’appel au pipeline formulaire_verifier.

Déclarez la dépendance à Saisies dans le fichier paquet.xml de votre plugin, afin que votre appel au pipeline passe systématiquement après celui de Saisies.
Déclarez dans votre paquet.xml l’appel au pipeline formulaire_verifier (lire la documentation sur programmer.spip.net)

Dans la fonction appelée, faites vos vérifications :

function <prefixeduplugin>_formulaire_verifier($flux) {
			if ($flux['args']['form'] == '<nomduformulaire>') {//Verification du formulaire <nomduformulaire> après que saisies ait vérifié
					$saisies =  saisies_chercher_formulaire($flux['args']['form'], $flux['args']['args'], true); // Trouver les saisies associées au formulaire, si besoin
					// Faire ses propres vérifications
					$flux['data']['<champ>'] = 'erreur' // Exemple pour ajouter une nouvelle erreur sur le champ <champ>
 
 
 
			}
			return $flux;
}

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Dans quelques cas rares, la structure globale du formulaire livrée avec Saisies ne convient pas. Pour autant, vous souhaitez.

profiter du formalisme de déclaration des saisies
profiter de la vérification automatique de ces saisies (sauf si vous utilisez la méthode 1a).

Dans ce cas :

vous mettez dans votre fichier formulaires/<nomduformulaire>.html la structure globale du formulaire correspondant à votre besoin;
là où vous souhaitez insérer vos saisies, vous utilisez la balise #GENERER_SAISIES.

Cette balise permet de générer toutes les saisies d’un formulaire, en une seule fois. Pour cela on lui passe en paramètre le tableau de description.

Exemple d’utilisation :

<form ....>
....
<div>
    #GENERER_SAISIES{#ENV{_saisies}}
</div>
....
</form>

On notera l’emploi d’un _ en préfixe de la variable d’environnement. Cela permet que les guillemets présents dans les options ne soient pas transformés en entités HTML [1].

#ENV{_saisies} :

est rempli automatiquement avec la valeur de retour de la fonction formulaires_<nomduformulaire>_saisies() si vous la déclarez ;
peut aussi être remplie manuellement en ajoutant une clé _saisies dans le tableau de retour de la fonction formulaires_<nomduformulaire_charger().

Méthode 2 : la balise `#SAISIE`

Parfois on veut pouvoir contrôler encore plus finement la présentation des saisies. Pour ce faire, on peut insérer dans formulaires/<nomduformulaire>.html des appels à la balise #SAISIE.

Cette méthode n’est pas toujours adaptée, car elle présente des limitations :

elle ne permet pas de profiter des vérifications automatiques;
elle ne permet pas de profiter du mécanisme d’affichage conditionnel.

#SAISIE permet de générer une seule saisie en lui donnant directement les paramètres désirés. Chaque saisie va générer une ligne dans un formulaire, c’est-à-dire soit :

un élément <li> selon les anciennes recommandations HTML des formulaires SPIP. Dans ce cas, il faudra entourer vos saisies d’une balise HTML <ul>.
un élément <div> selon la nouvelle recommandation HTML pour spip 3.x

La balise #SAISIE a deux arguments obligatoires : le type de saisie, et son nom HTML (attribut “name”). Toutes les autres options sont facultatives et servent à configurer le champ ; de ce fait, elles sont de la forme option=valeur.

La forme complète est donc la suivante :
#SAISIE{type, name, option=valeur, option2=valeur2, etc=etc}

Voici quelques exemples d’utilisation.

Génère un simple champ texte, indiqué comme étant obligatoire :
#SAISIE{input, email, label=Votre courriel, obligatoire=oui}
 
Génère un choix multiple parmi les utilisateurs du SPIP :
#SAISIE{auteurs, destinataires,
    label=Destinataires du message,
    explication=Choisissez une ou plusieurs personnes à qui sera envoyé le message.,
    multiple=oui}

Comme vous le voyez, des champs qui peuvent être complexes, et fastidieux à écrire de manière complète, s’écrivent ici en quelques lignes.

#SAISIE supporte le multilinguisme. Dans ce cas, attention de bien utiliser la syntaxe complète avec les crochets :

#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui} ne fonctionne pas ;
[(#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui})] fonctionne.

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Si votre formulaire est destiné à être public, le plugin se charge d’ajouter automatiquement les appels aux fichiers CSS et scripts Javascript associés aux saisies utilisées sur le site public, lorsque le formulaire est effectivement utilisé.forme

Toutefois, si vous avez beaucoup de formulaires utilisant Saisies sur le site public, il peut être judicieux de charger systématiquement les fichiers sur toutes les pages, afin de profiter de la compréhension et du cache navigateur. Dans la configuration du plugin (“Squelettes”->“Configuration du plugin Saisies”), une option permet d’activer cela.

Appendice 2 : enregistrer des tableaux

La norme HTML permet de gérer des réponses de formulaire sous la forme de tableau.

Dans la déclaration de la saisie, on peut utiliser la syntaxe HTML classique avec crochets :

array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'annee[debut]',
        'label' => 'Votre nom',
        'size' => 50
    ),
);

Mais il est recommandé d’utiliser le formalisme SPIP suivant : <tableau>/<clé>.

array(
    'saisie' => 'input',
    'options' => array(
        'nom' => 'annee/debut',
        'label' => 'Label,
        'size' => 50
    ),
);

Le code suivant permettra de récupérer la valeur en PHP :

$annee = _request('annee');
$debut = $annee['debut'];

Appendice 3 : la balise `#VOIR_SAISIES`

Cette balise permet d’afficher toutes les valeurs saisies après validation d’un formulaire. On lui passe en paramètre deux arguments :

le tableau de description des saisies (au même format que pour #GENERER_SAISIES)
un tableau des valeurs saisies

Exemple d’utilisation, dans le squelette d’un formulaire :

[(#EDITABLE|non)
    #VOIR_SAISIES{#ENV{mes_saisies}, #ENV}
]

Appendice 4 : problème avec Xdebug

Si vous développez en utilisant le logiciel Xdebug, il existe un problème connu : par défaut celui-ci affiche une erreur à partir d’un certain niveau d’imbrication de fonctions PHP (“nesting level” dirait Shakespeare).

Le niveau d’imbrication autorisé par défaut est relativement bas, mais on peut le paramétrer. Vous devez donc ajouter cela dans votre configuration PHP/Xdebug :

[xdebug]
xdebug.max_nesting_level = 200 ou 500 ou plus…

Et hop, ça remarche.

Footnotes

[1] Voir la documentation de la fonction _charger des formulaires CVT.

Discussion

5 years 1 year 3 months Without limit

par date

159 discussions

4

baloo

2 weeks ago

pour info. Je viens juste d’installer la version saisie V4.03 dans le répertoire plugin a la place de la précédente.
Immédiatement ... je ne vois plus dans configuration des plugins ( actif ou incaif) , les plugins non verrouillés par exemple inserer_modele il semble que cela soit ceux dont l’id est supérieur a celui de saisie dans la table plugin. Je vois ceux dont l’id est inférieur .

ils sont toujours dans la table plugin et dans le cache. J’ai effacé local et tmp... idem
- baloo
  
  2 weeks ago
  
  j’ai remis la version V4.02 .... mais je ne vois toujours pas les plugins.
  heureusement j’ai fait le test en local
- baloo
  
  2 weeks ago
  
  les plugins qui étaient déjà actif fonctionnent mais ne sont plus visible au niveau de la gestion des plugins.
- RastaPopoulos
  
  2 weeks ago
  
  Ton SVP a l’air un peu en vrac on dirait : &var_mode=reinstaller_svp
- baloo
  
  2 weeks ago
  
  merci ... les plugins sont visibles et actifs
Reply to this message
7
JuL BLoBuL

12 April
Bonsoir,
J’ai une question quant au format de texte (html ou brut) à utiliser dans les options (info_obligatoire) des saisies, car selon différent cas de figure j’obtiens différent résultat, je m’explique.
Un de mes clients insiste pour avoir des astérisques rouges pour les champs obligatoires dans un formulaire. Pour des raisons de confort technique j’utilise deux méthodes pour générer les saisies.
D’un coté j’utilise la syntaxe #SAISIE :
[(#SAISIE{input, firstname, label=<:zblobul_hanaf:prenom:>, explication = '', obligatoire= 'oui', info_obligatoire= <:zblobul_hanaf:info_obligatoire_asterix:>, defaut = #ENV{firstname}, })]
Dans mon fichier de langue :
'info_obligatoire_asterix' => '<b style="color:red">*</b>',
Jusque la tout a bien, côté utilisateur, j’obtiens un astérisque rouge.

J’utilise également la syntaxe php suivante :
$saisies[]= array(
’saisie’ => ’selection’,
’options’ => array(
’nom’ => ’levels’,
’label’ => _T(’choix_niveaux_cours’),
’obligatoire’ => ’oui’,
’info_obligatoire’ => _T(’info_obligatoire_asterix’),
’datas’ => $datas_levels,
)
);
Par contre, coté utilisateur, j’obtiens le code html :
<b style="color:red">*</b>
Le fait que j’utilise une chaine de langue ne change rien à l’affaire, j’ai testé sans.

Merci d’avance pour votre aide.

Julien
- Maïeul
  
  12 April
  
  coté PHP, dans l’environnement, ton tableau de saisies il porte bien un nom préfixé par _ ? dans le cas contraire il y a un echappement de la part de SPIP.
  
  Mais sinon, vu que de toute facon`info_obligatoire` passe automatiquement par `_T_ou_typo`, bah pas la peine de passer par `_T` côté php, tu met juste la chaine de langue en syntaxe spip (avec les chevrons).
  
  Je t’invite à relire la doc d’introduction à saisies ;-). Ainsi que le très bonne article de romy sur le signalement des obligations http://romy.tetue.net/signaler-les-champs-obligatoires
- JuL BLoBuL
  
  12 April
  Merci de l’info, j’ignorer qu’on pouvait se passer de _T pour les chaines de langue en php.
  Je viens de faire un teste :
  
  'info_obligatoire' => <:zblobul_hanaf:info_obligatoire_asterix:>,
  
  Mais ca passe pas :
  Parse error: syntax error, unexpected ’<’
- JuL BLoBuL
  
  12 April
  
  En tout cas effectivement il fallait effectivement que je rajoute le _ au nom de mon tableau de saisies.
  Cette subtilité m’échappe parfois, je l’ai pourtant mise en place sur la majorité de mes formulaires... Je me demande si l’inverse ne serait pas plus intuitif, devoir mettre le _ pour que spip échappe.
  Merci encore.
- RastaPopoulos
  
  12 April
  
  Après quand tu fais en PHP, ya quasiment aucune raison de faire le squelette toi-même justement. Comme l’indique la doc tu devrais plutôt laisser le squelette totalement vide et laisser Saisies générer cela bien comme il faut, en déclarant ton tableau dans tonformulaire_saisies(). De cette façon tu seras sûr que ça se génère comme il faut :)
- Maïeul
  
  12 April
  
  il manque les guillemets dans ton code php autour de ta chaine de langue :p
  
  quand aux règles de SPIP, ce sont les régles de spip, et j’ai tendance à penser que la sécurité par défut est une bonne régle (car n’oublie pas que #ENV peut potentiellement venir d’un POST)
- JuL BLoBuL
  
  12 April
  
  Oui RastaPopoulos, j’ai prévu de le passer complétement en php, c’est le cas mes formulaires en générale, mais celui-ci est long et compliqué, je l’améliore étape par étape ;)
  Pour Maieul, j’ai testé la syntaxe avec des apostrophes, sans succès, j’avais pas testé les guillemets ;)
  
  Merci à vous deux de vos lumières.
- Maïeul
  
  12 April
  
  oui alors apostrophe ou guillemet, je parlais bien de ce qui est utilisé en php pour définir un string :)
  
  En gros : si tu déclare en PHP, il faut utiliser la syntaxe de PHP :P
  
  (il vaut mieux préférer en général les simple quotes aux doubles quotes, car ces dernières impliquent une analyse du contenu à la recheche d’éventuelle $, donc un peu plus lent).
Reply to this message
7

Natacha Courcelles

6 April

Bonjour
ma question est un peu bête mais dans un formulaire j’ai besoin de sélectionner une brève
j’ai testé avec saisies/selecteur mais que des rubriques/articles
aucun des sélecteurs proposés ne concerne les brèves : normal ?
et y a t’il une solution ?
Merci
Natacha
- Maïeul
  
  6 April
  
  effectivement on n’a pas prévu la saisie breve, car... c’est un objet spip plus trop utilisé.
  
  Il faudrait
  
  1. Créer votre propre saisie en vous inspirant de la saisie articles
  2. Idéalement nous la partager pour qu’on puisse l’intégrer au plugin
- Natacha Courcelles
  
  6 April
  
  Merci Maïeul
  ceci dit je ne vois vraiment pas comment faire :-)
- Maïeul
  
  6 April
  
  commence par lire ceci https://contrib.spip.net/Creer-ses-propres-saisies (tu peux deja pour commencer te contenter de la première partie + éventuellement de la partie sur les héritages)
  
  Comme visiblement il n’y a nul part dans SPIP le besoin de selectionner une breve, tu pourrais te baser sur la saisie “selection” par ex.
- RastaPopoulos
  
  6 April
  
  Je suis dubitatif, car ça dépend du nombre : si l’idée des brèves c’est “des petits articles” et qu’ils peuvent être donc en quantité très importantes, genre des centaines ou plus dans chaque secteur, bah non un select va pas trop le faire… :)
  
  Je vois plutôt ça comme les sélections d’articles et de rubriques donc, mais c’est plus complexe à mettre en œuvre.
- Maïeul
  
  6 April
  
  effectivement. pour ce genre de cas avec beaucoup de choix, j’ai fait dans le cadre d’une association un input avec datalist. Ca marche pas trop mal (900 personne), mais je sais qu’à partir d’un certains nombre ca foire. peut être qqchose à base de choosen/select 2 ?
- RastaPopoulos
  
  6 April
  
  La manière graphique de le présenter à l’écran n’est pas trop ce qui me préoccupait là : c’est que c’est généralement mal de garder dans le HTML des centaines voire milliers d’éléments, juste pour permettre d’en choisir (ce qui est le cas avec ton datalist, ou un select qui utiliserait chosen). C’est bien pour ça que les sélecteurs d’articles et de rubriques ne fonctionnent pas comme ça (mais nécessitent ajax… mais c’est un gros défi de savoir faire des saisies dynamiques qui fonctionnent aussi sans JS).
- Maïeul
  
  6 April
  
  mais justement choosen a pas un API pour chercher en json, donc sans tout charger d’un coup ?
Reply to this message
3

Julien

9 March

La dernière mise à jour provoque une erreur :
Fatal error: Uncaught Error: Call to undefined function lire_config() in /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/plugins/auto/saisies/v3.49.0/saisies_pipelines.php:68 Stack trace: #0 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/inc/utils.php(199): saisies_affichage_final(’...’) #1 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/tmp/cache/charger_pipelines.php(142): minipipe(’saisies_afficha...’, ’...’) #2 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/inc/utils.php(265): execute_pipeline_affichage_final(’...’) #3 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/ecrire/public.php(176): pipeline(’affichage_final’, ’...’) #4 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/spip.php(26): include(’/home/clients/c...’) #5 /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/index.php(3): include(’/home/clients/c...’) #6 main thrown in /home/clients/c8e3a48a5548a86710a63b4bb37ed2fb/www/plugins/auto/saisies/v3.49.0/saisies_pipelines.php on line 68

Dès que l’on désactive le plugin, tout fonctionne...

Une idée ? CAr du coup ni GIS, ni champ extra, ni formulaire ne peuvent fonctionner !!
Merci de votre aide
Julien
- Maïeul
  
  9 March
  
  La v3.49.1 qui devrait être disposer dans quelques minutes corrige cela.
  
  https://git.spip.net/spip-contrib-extensions/saisies/commit/44ed5601
- Julien
  
  9 March
  
  MERCI !
  Et quelle réactivité !
- Julien
  
  9 March
Reply to this message
8
1138

December 2019
Bonjour.

Dans les commentaires de Formidable, j’avais posté les suggestions suivantes mais, comme je le supputais et comme Maïeul me l’a confirmé, ça relève plutôt de Saisies. Je me permets donc de le reposter ici :

Bonjour.

Quelqu’un me fait remarquer que, dans un champ date, le sélecteur d’années va de -60 à +40 ans (en 2019, on a donc le choix d’années entre 1959 et 2059).

Or une telle gamme n’est pas toujours souhaitée (on pourrait ne vouloir que trois années) ni toujours adéquate (pour une date de naissance, pas besoin des années à venir, mais probablement bien de dates en deçà de 1959).

Ne pourrait-il pas y avoir des options pour jouer sur l’étendue proposée ? On pourrait ainsi mettre de 2020 à 2022, ou de 1919 à aujourd’hui, ou d’aujourd’hui à 2042, etc.

Peut-être que ça existe déjà, mais je n’ai alors pas trouvé…
(Et peut-être que ça relève plus de Saisies que de Formidable…)

Et, tant qu’à faire, ne pourrait-on pas implémenter dans Formidable le champ HTML5
<input type="date" … >
, qui a le gros avantage de proposer une ergonomie plus adaptée sur appareils mobiles ?
(OK, il faudrait garder le système actuel en fallback pour les navigateurs qui ne le supportent pas encore, et je crains que ça coince pour Safari, où le type date est reconnu mais où aucun outil de saisie n’est présent.)

Plus d’infos sur le type date chez Mozilla…

Merci d’avance pour vos réponses, et bon week-end !

1138.

PS : dans la prévisualisation, le texte
<input type="date">
affiche réellement le champ . ;-)
- RastaPopoulos
  
  July 2020
  
  Tu peux faire un ticket sur la nouvelle forge pour cette demande ou tu veux qu’on le fasse ?
  https://git.spip.net/spip-contrib-extensions/saisies/issues
- Florence HENRY
  
  December 2020
  
  Bonjour
  
  je suis confrontée à ce problème. Y a-t-il du nouveau à ce sujet ?
  
  En attendant, quelle est la surcharge que je peux appliquer pour que mon formulaire (qui demande une date de naissance) puisse proposer des dates qui conviennent ?
  
  Florence
- RastaPopoulos
  
  December 2020
  
  Je ne crois pas qu’il y ait de nouveau. Par contre il n’y a toujours pas de ticket non plus. La première chose serait d’en créer un pour cette demande ici : https://git.spip.net/spip-contrib-extensions/saisies/issues
  
  Tu dois sûrement pouvoir surcharger la saisie, en appelant des paramètres différents de à la lib fournie par le core ? Sinon c’est qu’il y a une amélioration à faire directement dans le truc fourni par le core, et dans ce cas le ticket sur Saisies ne suffira pas.
- Florence HENRY
  
  December 2020
  
  J’ai fait le ticket.
  
  De mon côté (en attendant une éventuelle nouvelle option), je n’arrive pas à trouver à quel endroit la librairie est appelée. Tu as une idée ?
- Florence HENRY
  
  December 2020
  En ajoutant un bout de JS, j’arrive à ce que je veux, mais c’est pas idéal :
  
  $( ".datePicker" ).datepicker( "option", "yearRange", "1900:2020");
- Florence HENRY
  
  December 2020
  Je reviens sur ma tentative d’inclure un script JS dans mon header pour initialiser le calendrier avec les bons paramètres
  
  Le problème est que le code qui appelle la librairie Jquery.dateur.js est appelé dynamiquement en ajac après la fin du chargement de la page. (je le vois dans la console de mon navigateur).
  
  Du coup, mon code produit une erreur car la fonction `datepicker`n’est pas encore déclarée
  
  Uncaught TypeError: $(...).datepicker is not a function
  
  Comment faire pour que mon code soit appelé après ce code dynamique ?
- Michel Leble
  
  December 2020
  
  Bonjour,
  
  Vous pouvez essayer avec onAjaxLoad() .
  un exemple ici : https://programmer.spip.net/insert_head
  
  Sinon, pour un fix temporaire vous pouvez surcharger sous squelettes le javascript d’appel de Jquery.dateur.js (ou meme directement Jquery.dateur.js ) en rajoutant votre code derriere .
- Florence HENRY
  
  29 January
  
  Bonjour
  
  Merci pour la fonction onAjaxLoad(). C’est nickel.
Reply to this message
1
JBert

2 January
Bonjour à tous et excellente année 2021.

Je viens de tomber sur une chose un peu bizarre avec une balise #SAISIE.

Je passe à un formulaire l’identifiant de la rubrique courante pour que
l’utilisateur puisse sélectionner un article _de la même rubrique_. Le
passage de paramètre se passe bien, mais la saisie ne fonctionne pas
comme attendue.

J’ai écrit dans mon formulaire :
#ENV{id_rubrique} #SAISIE{selecteur_article, article_precedent, label='Article précédent', limite_branche=4} <- le 4 est normal, c'est un test #SAISIE{selecteur_article, article_suivant, label='Article suivant', limite_branche=#ENV{id_rubrique}}
Je récupère bien dans la sortie html la valeur 14 qui correspond à la
rubrique en cours. Voir pour cela la pièce jointe.

Comme je n’arrivais pas à faire fonctionner limite_branche, j’ai testé
la valeur de rubrique 4 (qui est la rubrique parente de la rubrique 14).
Là, comme on peut le voir, j’obtiens bien des liens sélectionnables sur
les trois rubriques présentes à ce niveau puis sur les articles contenus
dans ces rubriques qui fonctionnent (au css près qu’il faut que
j’adapte). Je m’attendais à trouver la même chose avec la rubrique 14
(qui contient naturellement des articles). À la place de cela, je
n’obtiens que le titre de la rubrique sans aucun lien vers les articles
de la rubrique en question.

J’ai essayé de voir comment était créé ce selecteur_article et ça m’a
renvoyé à prive/formulaires/selecteur/navigateur.html qui est un peu
cryptique.

Toute idée pour contourner le problème sera la bienvenue.

Bien cordialement,

JB
- JBert
  
  2 January
  Je me suis perçu trop tard que le code avait été mal transmis. Là, ça devrait être mieux... Désolé.
  
  #SAISIE{selecteur_article, article_precedent, label='Article précédent', limite_branche=4} #SAISIE{selecteur_article, article_suivant, label='Article suivant', limite_branche=#ENV{id_rubrique}}
Reply to this message
2

JuL BLoBuL

September 2020

Bonjour,
Il semble avoir une coquille dans la dernière version, j’ai des “[” qui apparaisse dans le label des champs date.
Merci
- Maïeul
  
  September 2020
  
  oui ca a été corrigé depuis, mais le tag n’avait pas été posé. La version 3.42.7 bientôt disponible corrige cela.
- JuL BLoBuL
  
  September 2020
  
  Ah ok, super, merci.
Reply to this message
4
DD

July 2020
Bonjour,
j’ai 3 erreurs identiques lorsque je recalcule une page article où il y a un formulaire :
1 Filtre saisies_nom2classe non défini plugins/auto/saisies/v3.42.1/saisies/checkbox.html _checkbox 66

Dans ce formulaire il y a 2 cases à cocher pour spécifier une valeur
0bjet de votre demande (obligatoire) Demande 1 Demande 2 Autre demande
+ 1 case à cocher pour s’inscrire à une newsletter.
Je ne sais pas laquelle pose problème.
Elle sont toutes décochées par défaut.

Avec Saisies pour formulaires 3.42.1 - stable

Merci
- RastaPopoulos
  
  July 2020
  
  évidemment cette version n’a durée que 5min et il a fallu que tu mettes à jour celle là :p
  
  j’ai refait le tag de cette version 5min plus tard sans la coquille donc il faudrait retélécharger cette version… sinon il faudra que j’augmente la version
- Maïeul
  
  July 2020
  
  mouais, on dirait qu’il y a un bug dans le système de cache du debardeur,
  cf le zip joint à cet article.
- RastaPopoulos
  
  July 2020
  
  Bon alors je viens de vérifier et apparemment le système ne refait pas le ZIP quand on supprime et refait le tag… :(
  
  Je modifie la version donc…
- DD
  
  July 2020
  
  Merci !
  Je ne fais pas de mise à jour tous les jours, mais là j’ai été trop rapide....
  
  j’ai fait
  3.42.1 à 3.42.2
  et l’erreur a disparu.
Reply to this message
1

JuL BLoBuL

June 2019

Bonjour,

J’ai une colle pour les meilleurs SAISISTES dans les parages.

J’ai fais un super formulaire CVT en exploitant à 200% SAISIES et c’est top ;) Par contre j’arrive à mes limites en souhaitant mettre de l’ajax et ne pas trop me salir avec du JS inutile.

Mon formulaire étant AJAXé via la class ’ajax’, j’aimerais pouvoir le recharger pour lui renvoyer une données saisies par l’utilisateur, je m’explique.

Il s’agit d’un formulaire d’inscription, et j’aimerais généré via SAISIES autant de champs (nom, prenom, emails) que nécessaire, selon le nombre de personnes spécifié par l’internaute via des ’selects’.

Pour ce faire j’ai commencé par rajouter du javascript dans l’html pour pouvoir déclarer un attribut onChange à mes selects... chose qui n’est pas possible via SAISIES (sauf erreur). Puis un script lancant un ’ajaxReload’ pour renvoyer le nouveau nombre d’inscrits en argument du formulaire, pour généré via une boucle mes champs (prenoms...), enfin bref, ca marche po.

L’ajaxReload ne fait rien du tout... Je ne suis pas d’ailleurs très sur de la syntaxe. Car AjaxReload prends en argument l’id du bloc ajax pour un inclure, mais pour un formulaire CVT c’est moi évident.

Donc si quelqu’un à un exemple sous la main, je suis preneur.

En vous remerciant,
JuL
- RastaPopoulos
  
  July 2020
  
  un an plus tard…
  
  il ne faut pas faire des ajaxReload car sinon tu vas perdre les saisies déjà effectuées, comme avec un rechargement de page quoi
  
  quand on veut recharger un formulaire CVT de SPIP avec des nouvelles informations, il faut *valider* le formulaire, mais détecter qu’on veut s’arrêter dans verifier() en générant une fausse erreur invisible qu’on n’affiche pas (c’est ce que fait la prévisu des forums par exemple)
  
  dans ce cas toutes les saisies sont conservées en mémoire, après à chacun de faire des choses en plus quand tu détectes qu’il y a ci ou ça dans l’environnement en plus (dans le charger() ou les saisies(), c’est après verifier(), donc si ya eu des set_request() ou autre dans verifier() tu peux les retrouver ensuite )
Reply to this message
4

JuL BLoBuL

June 2020

Re-Bonjour Rastapopoulos et Maïeul,
Je viens vers vous pour une question un complexe qui mériterait une documentation à part entière.
Il s’agit d’utiliser AJAX dans les formulaires CVT exploitant SAISIES (j’ignore si c’est le meilleurs endroit pour poster ce message)

Voici donc, j’ai un formulaire publique CVT dont tous les champs sont générés via le php puis inlcus dans le HTML via la balise #GENERER_SAISIES.
Je souhaite que le formulaire se recharge avec de nouveaux arguments au fur et a mesure de la saisie de ce même formulaire donc avant la validation de celui-ci.

Il s’agit d’un formulaire d’inscription a des activités, avec des inscriptions groupés ou on souhaite recueillir les noms des participants.
Actuellement, je récupère les noms des participants dans un TEXTAREA, ce qui n’est pas top à manipuler. je souhaiterais avoir autant d’input que de nom à saisir, pour les “serializer” lors du traitement du formualire.
J’ai cherché et testé puis abandonné...
Il y aurait un exemple sur lequel je pourrais m’appuyer?

Je sais utiliser l’ajax proposé par SPIP, mais comme il s’agit d’un formulaire je m’en sors pas.
Merci d’avance.
- Maïeul
  
  June 2020
  
  Reéponse coute : je ne sais pas.
  
  Réponse longue ; j’ai un besoin similaire
  
  Réponse très longue : la piste la plus prometteuse serait la saisie “groupe”, mais il faut la travailler pour la rendre accessible et générique.
- Maïeul
  
  June 2020
  
  heu, saisie “liste”.
  
  https://git.spip.net/spip-contrib-extensions/saisie_liste.git
- RastaPopoulos
  
  June 2020
  
  La saisie liste pour telle besoin précis ok, mais pour le besoin plus générique de “faire dépendre l’ajout de certaines saisies à la saisie d’autres trucs précédents” c’est forcément plus compliqué et plus générique.
  
  Deux possibilités :
  
  Tente avec les formulaires par étapes. Si à une étape t’as rempli un truc, tu récupère la valeur dans l’étape suivante, et tu mets pas la même saisie ou le même nombre de saisies.
  
  Plus globalement, même sans le système d’étapes qui prémache certaines choses, il s’agit d’utiliser le “verifier” quoi. Sachant que le charger (et donc la déclaration des champs quand on fait avec saisies) ça arrive APRES verifier et traiter. Donc normalement quand tu es dans la déclaration des champs, tu es capable de savoir la valeur d’un autre précédent, pour peu que t’as arrêté la validation durant “verifier”. Donc 1) quand tu postes un champ “nombre de participants” par ex, faut dire dans verifier() de s’arrêter, et 2) lors de ce deuxième chargement, faut mettre le bon nombre de gens à remplir. Un truc comme ça.
- JuL BLoBuL
  
  June 2020
  
  Effectivement le système de formulaire par étape pourrait être une solution.
  
  Originellement, j’aurais souhaité qu’un javascript intervienne comme on peut le faire avec l’AJAX des INCLURE permettant de recharger un bloc a distance avec des arguments.
  https://contrib.spip.net/Exemple-de-bloc-telecommande-en-Ajax
  Sauf que les blocs ajax des formulaires ne semble pas d’avoir d’ID ajax définissable contrairement au bloc INCLURE.
  
  La solution des étapes me semble une bonne piste effectivement, si la seconde étape prends en compte les données de la précédente, c’est déjà ca. Je pense toutefois que cela porte préjudice à l’ergonomie, en tout cas dans mon cas de figure ou le formulaire n’est pas très compliqué.
Reply to this message

« Previous 1 2 3 4 5 ... 16 Next »

Add a comment

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
- version de SPIP, en bas de la partie privée
- version du plugin testé et des éventuels plugins nécessités
- version de PHP (exec=info en partie privée)
- version de MySQL / SQLite / PostgreSQL
Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparait.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Who are you?

Name [Log in]

Email (not published)

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

Text of your message

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Notify me of new comments to this discussion by email

Add a document

gif, jpg, png

Follow the comments: |

Saisies

Introduction

Table of contents

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer une vérification

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise `#SAISIE`

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise `#VOIR_SAISIES`

Appendice 4 : problème avec Xdebug

Discussion

Discussions by date of activity

Add a comment

Saisies

Introduction

Table of contents

Méthode 1 : déclarer un formulaire CVT complet en PHP

Principe

Mise en œuvre

Déclaration de l’ensemble des saisies

Déclaration d’une saisie individuelle

Déclaration des saisies enfants

Appliquer une vérification

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications

Méthode 1b avec #GENERER_SAISIES : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise #SAISIE

Appendice 1 : chargement des CSS et scripts Javascript sur le site public

Appendice 2 : enregistrer des tableaux

Appendice 3 : la balise #VOIR_SAISIES

Appendice 4 : problème avec Xdebug

Discussion

Discussions by date of activity

Add a comment

Méthode 1b avec `#GENERER_SAISIES` : contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies

Méthode 2 : la balise `#SAISIE`

Appendice 3 : la balise `#VOIR_SAISIES`