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.
Pour utiliser l’API complète PHP, vous devez installer ou nécessiter le plugin YAML dans votre plugin. Ce n’est pas le cas quand on utilise juste la simple balise, ce pourquoi c’est à vous de le nécessiter.
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 4.11.0 ou 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 = […];
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 = [
[…], // une saisie
[…], // une saisie
[…], // 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 :
[
'saisie' => 'input',
'options' => [
'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 = [
'saisie' => 'fieldset',
'options' => [
'nom' => 'mon_groupe',
'label' => 'Mon groupe de champ'
],
'saisies' => [
[…], // une autre saisie
[…], // une autre saisie
[…], // etc
]
];Appliquer des vérifications
Pour des vérifications simples et uniques vous pouvez en déclarer des vérifications à appliquer sur chacune de vos saisies, avec le plugin API de Vérification (qui n’est pas activé automatiquement avec le plugin saisies).
Il faut alors ajouter une clé verifier selon ce formalisme :
[
'saisie' => 'input',
'options' => [
'nom' => 'slug',
'label' => 'slug',
'obligatoire' => 'oui',
],
'verifier' => [
[
'type' => 'taille',
'options' => ['min' => 10]
],
[
'type' => 'slug',
],
],
];Permet de vérifier que nous avons affaire à un slug d’une taille minimum de 10 caractères.
Consulter « Références des vérifications » pour la liste des types de vérification livrés avec le plugin et de leurs options.
[
'saisie' => 'input',
'options' => [
'nom' => 'nom',
'label' => 'nom',
'obligatoire' => 'oui',
],
'verifier' => [
'type' => 'entier',
'options' => [
'min' => 100,
'max' => 500
],
],
];Support du multilinguisme
Saisies supporte le multilinguisme. Ainsi, dans l’exemple ci-dessous, la chaine de langue <:cle:valeur:> sera automatiquement interprétée.
[
'saisie' => 'input',
'options' => [
'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 = [
'options' => [
// Changer l'intitulé du bouton final de validation
'texte_submit' => 'Valider c’est gagné',
…
'<option>' => '<valeur>' //Une autre option
],
[…], // une saisie
[…], // une saisie
[…], // 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 | |||
etapes_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'|'courante', 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_precedent_suivant_titrer |
Permet d’ajouter le titre des étapes dans les boutons « précédent » et « suivant » | True|False |
False |
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.
Pipeline
Lors du chargement des saisies déclarées via une fonction formulaires_<nom_du_formulaire>_saisies(), les saisies sont passés à un pipeline formulaire_saisies. Le tableau $flux passé à ce pipeline à la structure suivante :
- $flux['args']['form'] : le nom du formulaire ;
- $flux['args']['args'] : les différents arguments passés ;
- $flux['data'] : les saisies.
Il est donc possible à un plugin de modifier dynamiquement les saisies d’un formulaire en utilisant les différentes fonctions de l’API de saisies.
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 la création d’une fonction formulaires_<nomduformulaire>_verifier_post_saisie(), ou sa variante verifier_etapes_post_saisies() dans le cadre du multiétape.
À noter qu’il existe deux pipelines pour ajouter des vérifications à un formulaire existant : formulaire_verifier_post_saisies et formulaire_verifier_etapes_post_saisies.
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>.htmlla 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 :
<div class="formulaire_spip formulaire_#ENV{form}"[(#ENV{_etape}|oui)formulaire_multietapes]">
<form .... [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"]>
....
<div >
#GENERER_SAISIES{#ENV{_saisies}}
</div>
....
</form>
</div>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() [2].
On n’oubliera pas les attributs suivants :
- les différentes classes sur le <div> englobant
- l’attribut [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"] sur le <form>, qui permet de gérer correctement les affichages conditionnels des étapes dans un formulaire multi-étape.
Par ailleurs, on utilisera
[(#ENV{_etape}|oui)
<INCLURE{fond=formulaires/inc-saisies-cvt-etapes-#ENV{_saisies/options/etapes_presentation,defaut}, etapes=#ENV{_saisies_par_etapes}, env} />
]
</div>
pour insérer le chemin d'étapes, et
<cadre class="spip">
<INCLURE{fond=formulaires/inc-saisies-cvt-boutons,env} />pour les boutons de validation.
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 un élément <div>.
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 :
[
'saisie' => 'input',
'options' => [
'nom' => 'annee[debut]',
'label' => 'Votre nom',
'size' => 50
],
];Mais il est recommandé d’utiliser le formalisme SPIP suivant : <tableau>/<clé>.
[
'saisie' => 'input',
'options' => [
'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.
Discussions par date d’activité
179 discussions
Bonjour RastaPopoulos
Quand on créé un modèle de saisie perso, le plugin encapsule automatiquement un
<li>...</li>autour du code défini dans le modèle perso.Si je donne un paramètre « label » dans ma #SAISIE, alors le plugin génère le code
<label>....</label>Est-il possible de désactiver ce comportement pour ma saisie perso ?
c.a.d pas de
<li> et de <label>Pour info, j’ai créé une saisie perso avec les classes css de bootstrap, donc qui n’utilisent pas de
<li>Et mon label est utilisé dans le placeholder. Donc pas de
<label>.Cette saisie me permet d’afficher une icone à gauche de l’input.
MERCI
J’ajoute que l’icone que je veux rajouter à gauche de mon input est un glyphicon de bootstrap.
Donc cela ne peut pas être fait avec un background-image en css.
Je dois ajouter le code
<i class="icon-xxx">/<i>à gauche de mon input.Ce qui implique de modifier le code html habituellement utilisé dans SPIP.
Je continue mon monologue...
En regardant de plus près le fichier _base.html, qui, comme son nom l’indique, est appelé pour chaque saisie, je vois qu’il vérifie si type_saisie (par ex input_icone) est défini dans le tableau saisies_autonomes.
Si c’est le cas, la saisie perso (input_icone.html) est directement inclue, sans ajout des
<li>et autres traitements standards.Pour ajouter la nouvelle saisie dans saisies_autonomes, il faut utiliser un pipeline. Voir http://contrib.spip.net/Saisies-fai...
A priori, cela pourrait correspondre à mon besoin.
Mais...
Il serait tout de même plus judicieux d’utiliser la saisie INPUT existante. Et de jouer avec les CSS pour ajouter mon icone à gauche de la saisie. En utilisant le sélecteur li.editer_xxx:before (xxx nom du champ).
J’ai aussi plusieurs classes css à ajouter dans le li et le input, pour que cela fonctionne. Je pense pouvoir me débrouiller avec les paramètres li_class et class.
Répondre à ce message
Bonjour,
Suite à une mise à jour de spip en 3.1 depuis une 3.0.21 en local, le plugin saisie bloque le site.
Même après une mise à jour depuis spip_contrib.
Avez-vous eu cette erreur ?
Et quelles pistes possibles ?
Merci Alain
Répondre à ce message
Bonjour,
je souhaiterai que la personne qui a rempli le formulaire puisse avoir un N° unique en retour dans son email (pour faire un « RMA » = N° de retour atelier ).
Je pensais mettre le N° du formulaire rempli (« Id » que l’on voit dans le tableau des réponses).
Comment intégrer ce N° Id dans la réponse email SVP ?
Merci d’avance.
Tu confonds pas avec le plugin Formidable ?
Mais dans tous les cas, ce dernier a des traitements totalement séparés et il n’y a pour l’instant pas de moyen de savoir à coup sûr l’ordre d’exécution des traitements. En conséquence, il n’est pas possible d’être sûr que l’enregistrement en base (produisant alors un identifiant SQL) soit fait AVANT le traitement « envoyer par email ». Et du coup dans l’email on a pas moyen d’être sûr d’avoir un enregistrement en base sous la main.
En revanche on pourrait imaginer que tu ajoutes un champ « hidden » et que tu notes son nom (hidden_1) puis, si tu appelles ton formulaire en squelette uniquement (ça ne peut pas le faire pour un appel dans un contenu avec le modèle), tu peux pré-remplir le champ avec une valeur quelconque, donc tu peux produire un identifiant aléatoire et mettre la valeur dans « hidden_1 » au moment de l’appel (cf la doc de Formidable, appel en squelette, il y a un paramètre tableau pour pré-rempli les champs).
Bonjour,
merci de ta rapidité . C’est vrai je confonds, mais avec Forms&Table 2.5 .
Je vais tenter de ce côté là. Merci et désolé.
Répondre à ce message
Bonjour RastaPopoulos, avec SPIP 3.0.20, suite à la récente mise à jour saisies (2.5.20) l’enregistrement des traitements dans formidable (à jour : 2.9.5) semble perturbé.
J’ai bien la réponse :
Traitements activés
- Envoyer par courriel
- Enregistrer les résultats
Mais on dirait que la configuration n’est pas conservée. Je retrouve en cliquant sur « configurer le traitement » les cases « non cochées » suivantes :
- Envoyer par courriel
- Enregistrer les résultats
- Paiement
Et puis surtout la valeur des champs par défaut affiche désespéramment 1.
En revenant à l’ancienne version 2.5.19, tout rentre à nouveau dans l’ordre.
C’est corrigé en 2.5.21, merci du signalement
Répondre à ce message
Bonjour,
j’essaye d’obtenir un formulaire de réservation simple avec #SAISIE de date + horaire en utilisant le dateur de Bonux (plugin à jour).
Dans mon squelette de formulaire, tant que option « horaire=oui » est absente, tout va bien :
- >Date : 27/11/2015
Dès que j’utilise l’option « horaire=oui », la date affichée en prévisu devient « array », comme si aucune donnée de date n’était plus transmise par le formulaire :
- >Date : Array
C’est un problème connu ? J’ai beau farfouiller, je ne trouve pas de piste pour lever le problème.
Si quelqu’un a une piste... Merci d’avance.
LExi
Ma config :
SPIP Bonux 3.2.1 - stable
Saisies pour formulaires 2.5.16 - stable
SPIP 3.0.17 [21515]
Formulaire en question sans saisie d’horaire
De quelle prévisualisation tu parles ?
Il me semble que ça génère deux champs mais avec le même « name », avec les deux valeurs dans deux clés du même « name » : name=truc[date] / name=truc[heure]
Quelque chose dans ce genre : il suffit de regarder le HTML généré une fois que tu as activé l’option.
C’est donc à toi de récupérer correctement les valeurs suivant les champs que tu génères. Donc récupérer
#ENV{truc/date}et#ENV{truc/heure}et non pas juste#ENV{truc}Très juste, Rastapopoulos ! J’aurais dû y penser. J’ai trouvé deux inputs avec deux noms différents, du type name=« ma_date[date] » & name=« ma_date[heure] ». Cela fait sens avec l’obtention d’un « Array » à la place de la date dans le formulaire de prévisualisation. Merci de ton aide précieuse.
Ainsi dans la partie prévisualitsation de mon formulaire en html, je charge la date avec par exemple :
Je remarque cependant que, dans le fichier php, la fonction charger liste avec succès dans la variable $valeurs le champs de date comme un champs unique.
Comment traite-t-on ce champs pour l’envoyer à l’auteur ? Dans la fonction traiter, si je demande
... Je me retrouve de nouveau avec un array dans le email de réception.
J’ai essayé sans succès
Comme il est incompétent en php, il est de nouveau paumé le gars là. ;-)
Bé non,
_request('ma_date')est un tableau, donc il faut le récupérer tel quel dans une variable. Puis demander les deux clés$ma_date['date']et$ma_date['heure'].Message reçu. Mais ça, je ne suis actuellement pas capable.
Mais j’ai trouvé ça pour zapper la récupération dans une variable : selon Programmer Spip _request, si on souhaite récupérer certaines valeurs présentes dans un tableau, on peut passer ce tableau en second paramètre :
Or dans la fonction traiter de CVT
ne fonctionne pas. Selon ta remarque, il aurait été logique qu’il en fûsse autrement ;-). Ou il y a un truc qui m’échappe de nouveau ?
J’ai pas pigé de quoi tu parles, t’es pas capable de quoi, puisque tu fais déjà du PHP ?
Ya juste UNE ligne en plus par rapport au code que tu avais avant hein… Par exemple :
Moi j’ai pigé de quoi tu parles, et ça marche. Le php, c’est pas mon terrain de jeu. Voilà pourquoi je fais appel à spip depuis de si longues années. Donc je résume pour les nuls, qui flânent sur ce forum :
Pour utiliser #SAISIE de date + horaire en utilisant le dateur de Bonux, j’active le champs horaire avec la class class=« date heure » l’option horaire=oui. Exemple :
Dans la partie prévisualisation de mon formulaire en html, on récupère les valeurs saisies par :
Pour la partir php, dans la fontion traiter, _request(’ma_date’) est devenu un tableau, donc il faut le récupérer tel quel dans une variable. Puis demander les deux clés $ma_date[’date’] et $ma_date[’heure’].
A la bonheur !
Répondre à ce message
Bonjour, j’ai installé la dernière version du plug-in. Mais l’installation ne se fait pas correctement. Quand j’active le plug-in, j’ai bien le message qui me dit que l’activation du plug-in s’est correctement déroulée. Mais en fait il n’apparait pas dans la liste des plug-ins activés et reste dans la liste des plug-ins inactifs. Merci d’avance pour votre aide.
François
Répondre à ce message
Bonjour,
Je viens de faire la dernière màj du plugin « saisies » en version 2.5.17.
L’option html5 est postée sur mon site.
Pour la saisie suivante :
Je me retrouve dans le source de la page avec required=« required » !!
Est-ce normal ou ai-je raté quelque chose ?
Mais du coup, une sélection (non vide) est devenue obligatoire.
Merci par avance d’une explication ;-)
Il y a eu un ajout il y a 3 jours pour signaler en HTML5 que les listes déroulantes pouvaient être obligatoires.
Mais la modification que je vois test bien que la variable « obligatoire » soit présente ET différente de « non » pour s’activer. C’est là :
http://zone.spip.org/trac/spip-zone/changeset/91915/_plugins_/saisies/trunk
Donc je ne comprends pas comment en ayant « obligatoire=non » ça puisse l’activer…
Oui je lis bien la même chose et suis aussi surpris.
Si la condition n’est pas vrai, quelle peut-être la valeur de required ? Ne peut-elle garder une valeur précédente par défaut ?
Je reviens sur l’attribut ’obligatoire’ de la fonction ’selection’ :
J’ai supprimer l’attribut dans le paramétrage de la balise #SAISIE de mmon formulaire pour retrouver le fonctionnement d’avant évolution.
Mais sans comprendre l’origine du problème :-( J’ai simplement utilisé le premier terme de la condition (obligatoire existe : non).
Répondre à ce message
Bonjour,
J’aimerais savoir si il y a un moyen d’empêcher de sélection une date antérieur à la date du jour ?
C’est pour un champ date avec le pickdater...
Merci d’avance !
J’ai trouvé une solution avec jquery pour avoir comme date minimum celle du jour :
<script type="text/javascript">
$(document).ready(function() {
$('#champ_date_identifiant').datepicker("option", "minDate", new Date('[(#DATE|affdate{'Y/m/d'})]'));
});
// --></script>
En espérant que ça en aide d’autre !
Gilles L.
Et sinon c’est normalement possible à partir de ce commit :
https://core.spip.net/projects/spip/repository/revisions/21482
En envoyant dans la saisie l’option « attributs » avec dedans
data-yearRange="truc". Avec « truc » étant ce qu’on veut, je connais pas la syntaxe.Après avoir chercher un moment :
Si ça peut aider ....
Répondre à ce message
Bonjour,
Je cherchais à utiliser les codes de langue pour internationaliser mon formulaire en utilisant un fichier YAML pour générer mon formulaire. J’ai essayé avec :
Mais ça m’écrit « <:coordonnees:label_voie :> » dans le formulaire sans traduction.
Est-ce qu’il existe déjà une méthode prévue dans le plugin Saisie ou dans YAML pour effectuer la traduction des éléments label ? Ou faut-il se le faire à la main en parcourant récursivement le tableau après importation du fichier YAML et en appliquant la fonction _T sur les clés ’label’ du tableau ?
Si tu utilises bien
#GENERER_SAISIES{tableau}, ya déjà la fonction_T_ou_typo()qui est appliquée partout, donc ce n’est pas normal que ça ne soit pas déjà traduit.Salut Rastapopoulos,
J’ai identifié ce qui ne marche pas mais je ne trouve pas la solution au problème. Lorsque j’effectue yaml_decode_file, j’obtiens bien des :
'label'=>'<:coordonnees:label_voie:>', etc.Ensuite quand j’effectue un
[(#VALEUR**|var_dump)]dans le squelette inclure/generer_saisies.html, j’obtiens des :'label'=>"<:coordonnees:label_voie:>"Et du coup, la fonction _T_ou_Typo ne fait pas son boulot... Je n’arrive pas à trouver l’endroit ou les chaînes du tableau transmis à generer_saisies est transformé en entités HTML.
Ben dans charger(), toutes les valeurs de formulaire (= destinées à des champs HTML) sont échappées. Les autres doivent être envoyées avec un souligné devant :
array('_saisies' => $saisies)Youpi, merci, ça marche !
Avec dans ma fonction
charger:Et dans mon squelette :
[(#GENERER_SAISIES{#ENV{_mes_saisies}})]Tout fonctionne parfaitement ! Dans la doc, le paragraphe sur la balise
#GENERER_SAISIEmérite peut-être d’être amendé pour signaler cette subtilité ? Je crois que peu de personnes sont au courant du truc. Par exemple dans le plugin coordonnees, il est fait appel à la fonction_Tdans la fonctionchargerdans la déclaration du tableau transmis à#GENERER_SAISIE.Au fait, pour les curieux, le coup de l’underscore est expliqué ici : http://programmer.spip.net/Charger-les-valeurs-du-formulaire ... J’aurai pu effectivement trouver la solution en grattant encore un peu, enfin... en creusant beaucoup :)
Faut faire attention quand même : ne pas échapper des éléments risque d’entraîner des trous de sécu sérieux (de type XSS au moins). Le problème par rapport aux codes de langue c’est, à mon avis, qu’ils devraient être traités avant que le nettoyage html ne soit effectué.
@Gilles, « échapper » c’est une opération qui sert à protéger ce qui vient de l’extérieur, soit de l’environnement, soit d’une soumission de formulaire, etc. Là on parle d’un tableau PHP codé par un⋅e dev, le contexte est donc totalement différent. Et c’est bien pour ça qu’il existe les clés avec soulignement « _truc » dans le charger() de CVT : pour que les devs passent des valeurs internes sans rapport avec l’extérieur, et donc sans passage par l’échappement (qui peut casser bien d’autres choses que juste les chaînes de langue, ça ne suffirait pas de gérer juste ça).
Répondre à ce message
Bonjour
j’utilise la saisie des dates et j’aimerais savoir si on pouvait récupérer la valeur au format date directement Y-m-d plutôt que d/m/Y ?
Cordialement
Les saisies ne s’occupent que d’afficher des champs, pas de les traiter. Donc soit tu dois faire ça à la main (dans verifier() ou traiter() du CVT), soit tu peux utiliser le plugin Vérifier qui contient une vérification de date, et dans celle-ci il y a une option de normalisation de la valeur en datetime (avec l’heure par contre, quitte à ce qu’elle soit à 00h00, il faudrait peut-être ajouter une option date sans time).
OK, merci
J’ai bien assimilé que saisies ne s’occupe que d’afficher les champs. C’est tout de même saisies qui renvoie la date cliquée à un certain format. Je pensais que l’on pouvait choisir ce format..
Je vais donc garder ma solution actuelle de modifier le format dans la partie traitement.
Merci pour la réponse rapide
Théoriquement il y aurait la possibilité de changer le format de la valeur au tout dernier moment en JS, mais ça veut dire que ça obligerait à JS et que ça ne marcherait pas sans, ce qui est mal.
Là le fait de le faire après, ça permet qu’au niveau interface ça soit au format humain habituel (et dans l’ordre FR par défaut), mais qu’ensuite pour le traitement on le passe en format SQL-friendly.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
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.
Suivre les commentaires :
|
