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
Je vais créer des modèles de saisies additionnels. L’idée est de reprendre tous les modèles de saisie existants et d’ajouter une vignette en plus du label du champs. Souvent, une image est plus parlante que du texte.
Pour partager ultérieurement mon travail, est-il plus judicieux de :
- proposer les saisies additionnelles sous la forme d’un plugin, par exemple saisies-vignette ?
- proposer mes modèles pour une intégration dans le plugin SAISIES ?
- proposer mes modèles sous la forme d’un fichier à dézipper dans le rép. /saisies du squelette ?
A+
Peut-être qu’il y a plus simple encore que de redéfinir tous les modèles un par un :
J’ai modifié le fichier _base.html pour afficher la vignette (facultative) sous le label. OK facile.
Maintenant, il faudrait une sorte de surcharge automatique de tous les modèles de saisies, pour ajouter la saisie de l’Id du doc image pendant la définition d’un formulaire. De sorte que l’on ait pas à redéfinir tous les modèles de saisie existants.
Deux possibilités :
- soit j’inclue directement la fonctionnalité dans le plugin SAISIE. Sachant que si l’utilisateur ne donne pas de doc image, c’est l’affichage actuel qui est pris.
- soit je crée un nouveau plugin qui redéfinit _base.html et qui arrive à ajouter automatiquement un champs de saisie du doc image aux modèles de saisie existant.
Quel est l’avis de l’auteur(s) du plugin SAISIES ?
Merci pour votre support
Ajouter des images qui ne sont pas du contenu, c’est de la décoration. C’est donc du ressort des CSS, et on peut déjà parfaitement cibler tel ou tel champ pour ajouter un padding et une image devant son label, j’ai déjà fait ça plein de fois :
.editer_monchamp label{ styles }Si on veut utiliser des images qui viennent de la médiathèque, je crois qu’il est possible d’appeler une image dans le label, du genre
<img123> Mon texte.Mais dans tous les cas je ne crois pas qu’il y ait besoin de modifier le code actuel des squelettes.
Une image n’est pas toujours de la décoration. Elle a souvent un caractère informatif bien plus puissant que du texte.
Mettre un modèle
<doc123>dans le label, cela ne marche pas.Pour illustrer le besoin, voici une page : Checklist outils
Les images sont mises en vrac au début de l’article (pour qq heures encore).
Il y a ensuite une checklist qui permet à l’utilisateur de vérifier qu’il a tous les outils.
Il serait évidemment préférable que les vignettes des outils soient intégrées à l’intérieur de la checklist. C’est simplement une question d’ergonomie.
Il s’agit de décoration s’il y a de toute façon le texte : l’image n’est qu’une illustration du texte du label qui est le vrai contenu. Après on peut ne pas vouloir de texte mais juste une image avec un alt=« le texte », et dans ce cas là oui c’est l’image qui est le contenu.
Mais donc quand c’est de la déco, on style en CSS, et quand on veut une vraie image il faudrait que le modèle d’insertion fonctionne dans le champ. C’est ça qu’il faut modifier à mon avis. Et donc c’est pas dans le squelette mais dans le traitement du champ dans l’API.
En fait en vérifiant le code les champs passent effectivement par typo() donc par la gestion des modèles MAIS seulement si ya au moins un dans la chaîne.
Essaye avec
<multi><doc123> Mon label</multi>Génial ça marche en encadrant avec
<multi>...</multi>Je ne comprends pas pourquoi ça marche ? mais l’essentiel c’est que ça marche.
Répondre à ce message
Bonjour,
En local pour essai avec spip 3.05 de sept 2012, j’ai installé le plugin mosaïque qui demande une mise à jour de saisie et de champ extra.
C’est fait.
Tout fonctionnait bien jusqu’alors...
Dans la partie privée, j’ai ce message à la modification d’un article (il disparait en supprimant saisie et en replaçant une ancienne version de saisie.)
Ce n’est pas catastrophique (test) mais j’aimerais bien tester mosaïques...
Fatal error : Call to undefined function yaml_decode_file() in D :\Travail sur les sites\spip_v3\www\plugins\auto\saisies\inc\saisies_lister.php on line 290
Pour résumer, je n’ai pas le message avec l’ancienne version de saisies et j’ai accés à la rédaction des articles, par contre avec la dernière version de saisies, je ne peux plus changer mes articles.
Merci de toute façon pour cette contribution.
Je viens de charger et placer le plugin YAML, tout marche.
Je ne pensais pas avoir à surchager, puisque YAML est dans les plugins dist.
Merci excusez le bruit.
Répondre à ce message
Bonjour,
Tout d’abord un grand grand merci pour ce plugin. C’est fou le temps qu’il fait gagner. On code plus vite, la maintenance est beaucoup plus aisée. Bref que du bonheur.
Une remarque sur la version 1.26.12 : dans le fichier saisies/radio.html, ligne 25 il y a le code suivant
<div class="#ENV{choix,choix} #ENV{choix,choix}_#CLE">Pour une raison que j’ignore, il produit le HTML suivant :
<div class="choixchoix_maison">Les deux ’choix’ sont collés ce qui peut poser des micros soucis d’appel CSS ou JS.
ps : je précise que j’utilise SPIP 3.0.5
voilaaaa
Merci ! Et oui, j’oublie toujours ce BUG du compilateur de SPIP, qui supprime sans ménagement des espaces autour des #ENV.
Normalement corrigé par :
http://zone.spip.org/trac/spip-zone/changeset/66621
wowh ! Ca c’est de la correction rapide :)
et merci pour l’info concernant le bug du compilateur. J’ai pu corriger un problème...incompréhensible sans cette info.
cheers
Peetdu
Répondre à ce message
Dès que j’active Saisies en version 1.25.13 avec Spip 2.1.14 sous PHP Version 5.3.2, j’ai une page blanche. L’url est : ecrire/ ?exec=admin_plugin&actualise=1
J’ai tenté pas mal de choses comme :
- désinstaller tous les plugins,
- vider le cache,
- supprimer le dossier TMP,
- réactiver chaque plugin individuellement
Rien à faire, dès que j’active Saisies, ça coince, une idée ?
Une page blanche n’est pas une erreur précise. Sur le site de dev, il faut toujours activer l’affichage des erreurs pour savoir ce qu’il se passe plus en détail. Par exemple comme ça : http://www.spip.net/fr_article4453.html?var_recherche=debuggage#infos_plus
Merci, le message est :
Fatal error : Cannot redeclare picker_selected() (previously declared in /plugins/spip-bonux/spip_bonux_fonctions.php:76) in /prive/formulaires/selecteur/generique_fonctions.php on line 86
J’ai les extensions SPIP Bonux 2.3.0, Imprimer document 2 0.2 et CFG 1.16.0
Ben non c’est pas logique. Si la fonction est dans le noyau de SPIP, c’est que tu as SPIP 3, pas SPIP 2.1. Et dans ce cas c’est pas la bonne version de Bonux.
J’ai bien une 2.1.14 mais j’ai essayé de lancer spip_loader pensant que cela chargeait la dernière version de la série 2. Comme cela ne marchait pas, j’ai tout effacé et fait la mise à jour manuelle. Il y aurait des traces de la version 3 alors ?
Le fichier dont tu parles n’existe que dans SPIP 3. Tout effacer ça signifie tout effacer, sauf config/ et IMG/ (et squelettes/ s’il existe).
J’ai supprimé tous les répertoires sauf ceux contenant mes données et profité de passer sur SPIP 2.1.16. Cette fois ci, la validation du plugin s’est bien déroulée mais quand j’essaye de configurer Saisies :
ecrire/ ?exec=configurer_saisies
J’ai ce message :
Fatal error : Call to undefined function yaml_decode_file() in /plugins/saisies/inc/saisies_lister.php on line 290
j’avais le même message suite à une mise à jour 2.1.12 -> 2.1.19. De plus je ne voyais plus les plugins, activés ou non.
En FTP dans plugins/auto/ j’ai renommé le dossier saisie et verifier avec .old à la fin (saisie.old et verifier.old)
Depuis le spip, j’ai rafraichi la fenêtre plugins : bingo ! il me dit que verifier et saisie sont manquants....
Je retourne en ftp je leur rends leur nom (saisie et verifier)
Je n’ai plus qu’a réactiver ces 2 plugins dans le spip.
Cette méthode a marché pour moi. si ça peut aider
Bon courage
Répondre à ce message
Bonjour,
Je n’arrive pas à rendre une checkbox cochée par défaut.
J’ai tenté les configurations suivantes :
Avec également les mêmes valeurs entourées de guillemets, mais rien n’a fonctionné. Comment devrais-je m’y prendre ?
Tu parles de quoi ? En squelette ? et de quelle saisie parles-tu ? « case » qui est unique (comme oui_non mais en une case) ou bien « checkbox » qui gère plusieurs choix ?
Alors oui, je suis dans un squelette.
Et j’ai utilisé checkbox, mais je ne connaissais pas « case », qui me semble plus approprié pour ce que je veux faire (Une activation de plugin).
Finalement non, ça ne marche pas mieux avec « case ».
Voilà le code que j’utilise actuellement :
Et tu voudrais que ça fasse quoi ?
je voudrais juste que la case soit cochée par défaut, ce qui n’est pas le cas actuellement.
Il s’agit de l’activation /désactivation d’un plugin. je voudrais qu’il soit activé lors de son installation.
« defaut=on » donc avec la saisie « case » à priori
Remarque sur le besoin précis : c’est quoi l’intérêt de cette case vu que ya déjà une interface à SPIP pour activer/désactiver chaque plugin ? :)
Non, ça ne marche pas.
Sinon, pourquoi ? je sais que c’est redondant, mais je voulais donner la possibilité d’activer la fonctionnalité sur la même interface que le reste des options, pour plus de simplicité.
Mais c’est aussi pour ça que je voudrais que ça soit activé par défaut.
Arf, oui c’est vrai il ya un bug commun à « case » et à « oui_non » qui est que la valeur réelle doit être NULL pour que ça prenne la valeur par défaut à la place. Or le charger() de CVT ne renvoie jamais null mais chaîne vide, je crois.
On a pas encore trouvé de solution simple me semble-t-il. :(
Pas de souci, je ferai en sorte que ce soit une case « Désactiver » ;)
Et sinon, ce ’nest pas possible de vérifier uniquement par une égalité double et non triple dans le plugin ? Ou ça causerait plus de souci que ça n’en corrige ?
C’est pas une question d’égalité triple, c’est un test « is_null ». Car Les deux valeurs possibles pour une case sont soit remplie avec une valeur, soit chaîne vide. Or faut pouvoir différencier « chaîne vide » qui veut dire « pas cochée » de « null » qui veut dire « ya pas de valeur pour l’instant ».
Ok, merci pour les précisions !
Répondre à ce message
Bonjour Rastapopoulos,
Ce serait super une saisie Fichier_joint qui joindrais dans tmp/
genre :
[(#SAISIEfichier, f_joint, , label=Votre cv, dossier=« mon_dossier »)]
J’aimerais bien mettre une issue mais je sais pas où ca se passe.
Peut être d’autres aimeront ?
Merci pour ce plug en tt cas que j’utilises à toutes les sauces
++
Répondre à ce message
Bonjour,
Voici le message d’erreur avec la version de SPIP et la dernière version du plugin « Saisies » avec l
SPIP 2.1.16
version du plugin saisies 1.26.5
Parse error : syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ’}’ in /mnt/106/sda/5/1/lpg45/plugins/saisies/balise/saisie.php on line 13
Merci
PHP 4 n’est plus supporté, il te faut PHP 5 (voir la doc de ton hébergement, souvent une ligne dans un .htaccess)
Merci à vous maintenant c’est OK en créant le fichier .htaccess à la racine de mon site et en écrivant dedans seulement <php5> .
Répondre à ce message
Bonjour,
tout d’abord merci pour le plugin, qui me sert beaucoup.
J’ai juste une suggestion à vous faire, pour l’améliorer. Je ne suis pas spécialiste, donc c’est à valider, notamment au niveau de l’impact sur le reste du plugin
J’utilise un fichier YAML pour spécifier mes formulaires puis les envoyer à GENERER_SAISIES (j’ai piqué l’astuce ici : http://contrib.spip.net/Doc-Saisies-complementaire)
Par contre les chaines de langue sur les labels ne fonctionnent pas si on les mets telles quelles dans le YAML
J’ai réussi à les faire traduire automatiquement par GENERER_SAISIE en remplaçant, dans _base.html « #ENV*label » par « (#VAL#ENV*label|_T) » et en .
Il faut spécifier dans le YAML la chaîne de langue au format « code:id_chaine » et ça roule. Si ce n’est pas une chaîne de langue qui est spécifiée dans le YAML, le nom est affiché tel quel.
Si un des développeurs pouvaient confirmer, ça serait cool.
Merci !
Pierre
avec les balises code ...
P.
Depuis le début, les saisies acceptent de mettre en paramètre des chaines de langue comme dans les squelettes :
<:préfixe:code:>, c’est utilisé partout, y compris pour les fichiers de config des saisies elles-mêmes (cf saisies/*.yaml).Arf.
effectivement c’est utilisé dans les fichiers du répertoire « saisies »
par contre je ne comprends pas pourquoi ça ne fonctionne pas chez moi.
Il m’affiche <:code:id_chaine :>
je vais investiguer
Merci d’avoir pris le temps de répondre ..
P.
Bon, je n’ai pas réussi à comprendre pourquoi ça ne marche pas.
Si quelqu’un pouvait m’aider, je l’en remercie par avance.
SPIP 3.0.4 [19781]
Saisies 1.26.5
PHP 5.3.13
MySQL 5.5.24
extrait de mon YAML
j’ai aussi testé avec :
extrait du code qui parse le YAML (dans formulaires_editer_objet_charger_dist)
et dans mon formulaire :
extrait de mon fichier de langue objet_fr.php (qui est bien reconnu ailleurs dans l’espace privé)
Je précise que j’affiche tout ça dans l’espace privé.
Merci d’avance !
P.
Alors :
Pour cela il faut créer une fonction
formulaires_truc_saisies_dist($arg1, $arg2, etc)sur le même modèle sur charger(), verifier() etc. Cette fonction doit renvoyer un tableau PHP de saisies, selon la norme de ce plugin. Ce tableau soit tu l’écris directement dans cette fonction, soit tu le fais venir d’où tu veux, peu importe. Lorsque cette fonction existe, SOIT tu laisses le HTML du formulaire VIDE (mais le fichier doit exister) et dans ce cas Saisies te construit le formulaire entier, SOIT c’est toi qui fait le squelette et tu peux récupérer le tableau des saisies dans#ENV{_saisies}. Tu as pas mal d’exemple d’utilisation de cette API déjà sur la zone : http://zone.spip.org/trac/spip-zone/browser/_plugins_/produits/formulaires/configurer_produits.phpMerci beaucoup de ta réactivité !
Ca fonctionne !
Pierre
Répondre à ce message
Bonjour
c’est a dire que les plugins fonctionnant avec (saisie) ne fonctionne pas on me demande de telecharger l’ancienne version, avec la nouvelle , les plugins ne fonctionnent pas
Qui ? Quoi ? Où ? Quand ? Quelles versions ? Quel SPIP ? Expliques vraiment ton cas d’utilisation, parce que là c’est un peu flou.
Répondre à ce message
Bonjour
aprés mise à jour version 1.25.4 de ce plugins, plus rien ne fonctionne avec les plugins ayant besoin de celui-ci, on me demande de remmettre l’ancienne version 1.24 bien entendu que je ne trouve plus
qu’en pensez-vous
Ça veut dire quoi « plus rien ne fonctionne » ?
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 :
|
