Saisies

Publié le : 27 mars 2010 – Dernière modification le 4 novembre 2023 – par Maïeul, RastaPopoulos – 751 commentaires

75 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.

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.

Pour les versions du plugin < 4.3.0, il n’est possible de déclarer qu’une seule vérification par saisie, sous la forme :

[
    '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>.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 :

<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.

Notes

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

[2] Historiquement, elle pouvait aussi être remplie manuellement en ajoutant une clé _saisies dans le tableau de retour de la fonction formulaires_<nomduformulaire_charger(), toutefois ceci ne permet pas de bénéficier de tous les mécanismes d’automatisme du plugin saisies, et les bugs risquent d’être présents. Ce n’est donc pas une fonctionnalité officiellement supportée et validée.

Voir aussi la doc complémentaire et participative sur le wiki :
Saisies : Doc complémentaire

Discussion

5 ans 1 an 3 mois Sans limite

par date

179 discussions

2

nicolas

Novembre 2010

Bonjour,

j’ai un problème dans l’utilisation de l’option afficher_si pour des checkbox. Je voudrais dans un formulaire CVT que le fait de cocher une case fasse apparaître d’autres cases à cocher (et bien sûr si la case n’est pas cochée les autres choix ne sont pas proposés). J’arrive bien à utiliser l’option avec des boutons radio mais pas avec des checkbox.
J’utilise bien la balise #GENERER_SAISIES dans le fichier html de mon formulaire.
Si quelqu’un a une solution je lui en serais très reconnaissant.
Merci.
- RastaPopoulos
  
  Décembre 2010
  
  C’est Joseph qui a ajouté ça et je n’ai encore jamais eu le temps de jeter un œil sur le code. Donc il faudrait plutôt lui demander, mais je ne sais pas s’il passe par ici. Sur la liste SPIP-Zone ça aurait plus de chance par contre. Enfin je le croise virtuellement, je lui demanderai.
- nicolas
  
  Décembre 2010
  
  Bonjour et merci d’avoir pris le temps de me répondre.
  Est-il possible de contacter joseph par courriel ?
  Sinon je suis toujours intéressé par la solution s’il vous la donne lors d’une rencontre virtuelle (j’ai pour l’ instant contourné le problème avec des boutons radio mais cela ne me satisfait pas vraiment.)
Répondre à ce message
2

JLuc

Août 2010

La fonction saisie_autonome n’a pas pas l’air surchargeable.

Dés lors comment composer des saisies complexes ou des saisies qui ne passent pas par _base.html ? obligé de passer par fieldset ?
- JLuc
  
  Août 2010
  Je me répond :
  
  1) mais si elle est surchargeable puisqu’elle appelle le pipeline du même nom
  
  2) on peut aussi se contenter de surcharger _base.html pour étendre la liste des saisies ’autonomes’ puisqu’il n’y a que là pour l’instant que cette fonction est appelée.
  
  A la place de #SET{saisies_autonomes,#VAL|saisies_autonomes} faire
  
  #SET{saisies_autonomes,#ARRAY{{fieldset, hidden, destinataires, explication, cequonveutenplus}}
- RastaPopoulos
  
  Août 2010
  On a pas dû lire le même code de la même fonction.
  
  $saisies_autonomes = pipeline('saisies_autonomes', array(.....));
  
  On peut difficilement plus propre qu’un pipeline pour surcharger, non ?
Répondre à ce message
1

JLuc

Août 2010

Je suis tombé sur une erreur « undefd function » en utilisant GENERER_SAISIES avec un array (fieldset...). C’était une fonction définie dans le plugin yaml qui manquait. yaml devrait donc apparemment apparaître en ’necessite’ ou ’utilise’ dans plugin.xml
- RastaPopoulos
  
  Août 2010
  
  Non car on peut très bien utiliser Saisies sans utiliser les fonctions de l’API. Et utilise ne ferait rien dans ce cas. C’est juste que si a besoin de l’API là on a besoin de YAML. C’est donc au plugin qui utilise Saisies *avec* l’API qui lui doit nécessiter YAML.
Répondre à ce message
12
Maïeul

Juin 2010
Sur la dernier SVN, j’ai l’impression que #GENERE_SAISIES est en panne.

en gros voici ma fonction charger :
function formulaires_tedeum_charger(){ //spip_log('ca passe','tedeum'); $saisies = array( array( 'saisie' => 'radios', 'options' => array( 'nom' => 'origine', 'label' => 'Origine sociale', 'datas' => array( 'noblesse_epee' => 'Noblesse d\'épée', 'noblesse_cloche' => 'Noblesse de cloche', 'haute_noblesse' => 'Haute noblesse (enfant illégitime)', 'haute_bourgeoisie' => 'Haute bourgeoisie', 'petite_bourgeoisie'=> 'Petite bourgeoisie (marchand)', 'artisans' => 'Artisans', 'laboureurs' => 'Laboureurs', 'domesticite' => 'Domesticité', 'paysannerie' => 'Paysannerie', 'gueux' => 'Gueux' ) ) ) ); return array('_saisies'=>$saisies); } ?>
dans le le fichier formulaires/tedeum.html
<div class="formulaire_spip formulaire_tedeum"> <form action="#ENV{action}" method="post"><div> #ACTION_FORMULAIRE{#ENV{action}} #GENERER_SAISIES{#ENV{_saisies}} <p class="boutons"><input type="submit" class="submit" value="<:pass_ok:>" /></p> </div></form> </div>
et voilà ce que ca produit
<div class="formulaire_spip formulaire_tedeum"> <form action="./?page=tedeum" method="post"><div> <div><input name="page" value="tedeum" type="hidden" /><input type='hidden' name='formulaire_action' value='tedeum' /><input type='hidden' name='formulaire_action_args' value='wYGZghipio/vFk0v/dqZN7qbFOeUTr7Bvfcwb9qa1se0rv1WEKq0wx6xxjhdOdINswl1JjUgB40SWzqOPZCLjzICvkFSQXc=' /></div> <p class=\"boutons\"><input type=\"submit\" class=\"submit\" value= <p class="boutons"><input type="submit" class="submit" value="OK" /></p> </div></form> </div>
Je suis en 2.1
- Maïeul
  
  Juin 2010
  
  mais quand on est bête ! J’avais mis saisies d’en extensions mais pas repassé par la case plugin->il était pas activé.
  
  dsl pour le bruit
- Yffic
  
  Juillet 2010
  Hello
  
  Je cherche un exemple de la fonctionnalité « verifier »... J’ai un truc comme ca :
  
  2, #ARRAY{ saisie, input, options, #ARRAY{ nom, speed, label, <:sjcycle:speed:>, defaut, 2000, }, verifier, #ARRAY{ type, entier } },
  
  Je pensais que ca se branchait tout seul sur l’api de vérification, mais apparemment non... Donc comment faire ?
- RastaPopoulos
  
  Juillet 2010
  
  Tu as déjà posé la question sur la liste et je t’ai déjà répondu là-bas. :)
  
  Déjà il n’y a pas d’API de vérification automatique, c’est toi qui doit appeler ci ou ça.
  
  La plugin Saisies fournit dans son API, une fonction nommée saisies_verifier(). À toi de l’utiliser.
- Yffic
  
  Juillet 2010
  
  OK, mais à quoi sert le plugin « verifier » du coup ?
- RastaPopoulos
  
  Juillet 2010
  
  Ben a fournir l’API de vérification !
  
  saisies_verifier() « lit » ta déclaration dont tu parles, et appelle l’API de Vérifier pour appliquer ce que tu as déclaré.
- Yffic
  
  Juillet 2010
  OK, faut m’expliquer longtemps, c’est l’age...
  Si j’ai bien compris, faut passer par #GENERER_SAISIES placer entres les ul du formulaire. Avec un tableau php créé dans la fonction charger du formulaire et utiliser saisies_verifier() dans la fonction de vérification du formulaire en lui passant $formulaire en paramètre.
  
  Mais est-ce sensé fonctionner aussi avec cfg ? #GENERER_SAISIES n’affiche rien :
  
  config_plugintest_fonctions.php :
  
  function cfg_config_plugintest_charger(&$cfg){ $saisies = array( array( 'saisie' => 'input', 'options' => array( 'nom' => 'age', 'label' => 'Age', 'size' => 2), 'verifier' => array (type, entier) ) ); return array('_saisies'=>$saisies); }
  
  et dans config_plugintest.html :
  
  #ACTION_FORMULAIRE{#ENV{action}} <ul> #GENERER_SAISIES{#ENV{_saisies}} </ul>
- RastaPopoulos
  
  Juillet 2010
  
  Euh je ne connais pas cfg_config_plugintest_charger. Dans tout formulaire CVT c’est formulaires_montruc_charger().
- Yffic
  
  Juillet 2010
  
  Ben je ne l’ai pas inventé, j’ai vu ça dans un plugin de kent1 et j’ai fini par trouver la doc : http://www.spip-contrib.net/API-CFG...... Est-ce donc à cause de ce fonctionnement particulier de CFG que generer_saisies ne fonctionne pas ?
- RastaPopoulos
  
  Juillet 2010
  
  Ah oui c’est vrai qu’avec CFG, dès qu’il y a une des fonctions de CVT, ça ne marche plus justement. Ben je sais pas alors, je connais pas du tout l’API CFG. Si tu as aussi Bonux sur ton site, ya peut-être moyen d’essayer l’API de configuration mise en place par Cédric, qui fait pareil que CFG mais avec CVT.
- Yffic
  
  Juillet 2010
  
  OK, je vais voir... Mais il se trouve ou ce plugin ? ou plutot comment qu’il s’appelle ?
- RastaPopoulos
  
  Juillet 2010
  
  Ben c’est Bonux t’ai-je dit. Faut fouiller sur la liste dev je crois pour trouver la doc, ou bien dans le code de Bonux, dans le dossier /configurer/.
- Yffic
  
  Juillet 2010
  
  OK merci pour les infos
Répondre à ce message
1

Firouz

Juin 2010

Sujet : comment ajouter de nouveaux champs entrées item dans Formidable générateur de Formulaire
J’ai pu installer et faire fonctionner Formidable générateur de Formulaire sur squelette sarkaspip3.0.3
avec spip2.1 en local sur wamp1.7.0
Comment avec ce plugin très intéressant dont j’admire la réalisation :
on peut ajouter des champs supplémentaires en plus de ceux qui existent :
- je ne sais pas ou regarder
- c’est dans la partie fonctionnelle ?
- CVT j’ai du mal à comprendre
- par où commencer
- faut aller ajouter des scriptes dans un plugin , mais lequel et comment ?
Merci de votre aide, et excusez moi de mon ignorance, car je débute sur ce sujet
- RastaPopoulos
  
  Juillet 2010
  Vous voulez ajouter de nouveaux types de champs, si je comprends bien ?
  
  Il faut donc tout simplement ajouter des Saisies, ainsi que leur description dans un fichier YAML du même nom.
  
  Par exemple dans votre dossier squelettes/ ou dans votre plugin à vous, il faut créer un dossier saisies/ dans lequel vous mettrez des couples de fichiers HTML/YAML.
  
  ma_saisie_a_moi.html
  ma_saisie_a_moi.yaml
  
  Le fichier YAML permet de décrire le nom humain qu’aura la saisie dans Formidable, son icône ainsi surtout que toutes ses options.
  
  Pour vous aider, il suffit de vous inspirer des fichiers YAML qui existent déjà dans le plugin Saisies. Vous en copiez un et vous partez de ça pour décrire vos propres options.
Répondre à ce message
6

Yffic

Juin 2010

Bonjour

J’aimerais pouvoir inserer un texte d’explication en intro d’un fieldset. Ce n’est pas possible apparemment, est-ce une evolution envisageable ?
- RastaPopoulos
  
  Juin 2010
  
  N’est-ce pas pourtant le but de la saisie « explication » ? :)
- Yffic
  
  Juin 2010
  
  Tout à fait, je ne voyais rien dans l’article des références... Je l’ai trouvée en fouillant dans le code...
- RastaPopoulos
  
  Juin 2010
  
  Ah mince, il faut mettre à jour l’article.
- RastaPopoulos
  
  Juin 2010
  
  Voilà l’article des références a été mis à jour.
- Yffic
  
  Juin 2010
  
  Hello, b_b viens de me faire découvrir l’option « couleur » aussi qui n’est pas dans les références
- RastaPopoulos
  
  Juillet 2010
  
  Oui c’est parce qu’en fait les références sont construites automatiquement à partir des descriptions YAML des saisies. Or je n’ai décrit en YAML que les saisies qui avaient vocations à être utilisable dans Formidable par le commun des mortels.
  
  C’est un peu bête, ouais. Sinon faut la décrire quand même, mais du coup cette saisie se retrouvera dans la liste des champs possibles de Formidable. C’est pas un drame hein, ça peut toujours servir.
Répondre à ce message
4

Yffic

Juin 2010

Salut

J’utilise SAISIES dans un formulaire de config de plugin. Je ne pige pas comment se fait l’initialisation de la valeur par defaut. Par exemple si je rajoute valeur : #ENV{valeur} au debut du fichier saisies/oui_non.html, ca m’affiche « on » meme si je n’ai rien dans la table meta de mon plugin. Du coup le test suivant du même fichier #SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}} ne prend jamais la valeur « defaut » que je defini dans le formulaire... Je ne pige pas bien ce fonctionnement et surtout d’où vient le « valeur » de l’environnement ? Si tu peux me donner une piste de recherche...

Merci
- Matthieu Marcillaud
  
  Juin 2010
  Je comprends pas trop ce que tu dis...
  
  Ça s’utilise comme ça le défaut il me semble :
  
  defaut à non : [(#SAISIE{oui_non,tenveux, defaut='', label="T'en veux ?"})] defaut à oui [(#SAISIE{oui_non,tenveux, defaut=on, label="T'en veux ?"})]
- Yffic
  
  Juin 2010
  
  Oui, pas facile d’être clair...
  
  D’abord, si tu va voir le code http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/oui_non.html moi je comprend que ce qui est testé c’est oui ou non pour définir le bouton qui cheched : [ (#GET{valeur}|oui)checked='checked']
  
  Effectivement toujours dans le même tag input, c’est l’attribut value qui vaut « on » ou rien. Donc a priori c’est « on » ou rien qui est enregistré dans la meta...
  
  Mais admettons qu’on n’a pas de meta, d’où vient #ENV{valeur} en début de ce fichier ? Si je lit bien cette ligne #SET{valeur,#ENV{valeur}|is_null|?{#ENV{defaut},#ENV{valeur}}} : si valeur n’est pas définie dans l’environnement, on crée la variable valeur en l’initialisant avec defaut définie dans l’environnement... Et ça, ça n’a pas l’air de fonctionner.
- Matthieu Marcillaud
  
  Juin 2010
  c’est automatiquement calculé... #SAISIEx,y n’est qu’un raccourcis pour écrire (de mémoire) :
  
  #INCLURE{fond=saisies/_base,type_saisie=x,nom=y,valeur=#ENV{y}}
- Yffic
  
  Juin 2010
  
  Merci Matthieu...
  
  Tu as bonne mémoire. J’ai pigé : Pour « checker » un bouton radio, on peut mettre n’importe quoi dans « defaut » et pour le « unchecker », il ne faut rien mettre.
Répondre à ce message
3

rémi

Juin 2010

Bonjour,

J’ai un problème avec le plugin FancyBox qui utilise Saisies pour être activé. Lorsque je vais sur la page publique (un article comportant des photos) utilisant ce plugin, il m’affiche une erreur :

Erreur : $(« li.fieldset.pliable ») is null Fichier Source : http://www.myspherelife.com/plugins/auto/saisies/javascript/saisies.js Ligne : 8

J’ai donc désactivé tous les plugins sauf Bonux (v 1.9.7) et Saisies (v 1.7.5) et l’erreur est toujours là. Je précise que je suis sous SPIP 2.1. Le cache est vide, idem pour celui de mon navigateur. Je suis sous FF 3.6 et j’ai testé sous IE 8, même problème.

J’ai désactivé mes scripts js persos présents sur la page. Du coup je vois plus trop ce que je peux faire et j’aurais voulu savoir ce que vous en pensiez.

Merci.
- RastaPopoulos
  
  Juin 2010
  
  Je n’ai cette erreur sur aucun de mes sites où se trouve Saisies, donc je ne comprends pas. Surtout le code en question n’est pas bien complexe : si ça trouve des « li.fieldset.pliable » alors ça fait ceci-cela. S’il n’en trouve pas, ça ne doit tout simplement rien faire. Donc ce n’est pas normal que ça puisse générer une erreur lorsqu’il ne trouve rien, surtout s’il n’y a plus rien d’autre du tout que ce script.
  
  Vraiment là, je ne comprends pas. :(
- RastaPopoulos
  
  Juin 2010
  
  Je viens de faire de tests sur ta page et tu dois avoir une erreur de chargement de jQuery. C’est comme s’il ne trouvait pas du tout jQuery.
  
  Sur ta page j’ai lancé des scripts basiques du genre : $('div') pour que jQuery me liste toutes les balises div, et même là il me sort « null ». Donc il y a un problème plus en amont de le script de Saisies.
- rémi
  
  Juin 2010
  
  Je viens de renvoyer via FTP tout SPIP 2.1, j’ai également vidé le répertoire /tmp, on sait jamais. Toujours l’erreur :-/
  
  Je vais essayer de remonter dans la hiérarchie de SPIP pour voir du côté de jQuery. Merci pour l’aide :)
Répondre à ce message
4

goetsu

Juin 2010

comment faire pour empecher saisie.js d’etre chargé sur les pages publics ?
- RastaPopoulos
  
  Juin 2010
  
  On ne peut pas pour l’instant. C’est pour quel besoin ?
- goetsu
  
  Juin 2010
  
  c’est car je n’utilise pas le jquery natif et du coup j’ai une erreur js venant de saisie car il ne trouve pas onAjaxLoad
- RastaPopoulos
  
  Juin 2010
  
  Les ajouts jQuery de Saisies sont utilisés par la saisie « fieldset » pour l’instant, et bientôt pour d’autres saisies pour différents besoins. Je ne vois pas trop comment détecter automatiquement tous les usages possibles et s’ils sont effectivement utilisés dans la partie publique à tel ou tel moment précis. Donc le javascript est toujours présent, vu le peu d’octets qu’il contient... Et effectivement il n’est pas pensé pour fonctionner sans les scripts ajoutés par SPIP (qui ne sont pas « jquery » d’ailleurs, mais des scripts ajoutés en plus à côté aussi).
  
  Donc plusieurs solutions :
  - est-ce que tu veux juste changer la version de jQuery ? Dans ce cas tu devrais faire en sorte que ça ne supprime pas les ajouts que fait SPIP (et qui sont bien dans des fichiers autres que celui du jQuery de base).
  - sinon on peut aussi ajouter une constante qui permettrait de désactiver le chargement du js de Saisies dans la partie publiques.
  
  En fait même si on fait la deuxième solution pour les cas extrêmes, cela n’empêche pas la première : en effet si toi tu enlèves carrément jQuery, là je comprends que ça ne puisse pas marcher ; mais si tu utilises juste un autre jQuery, pourquoi est-ce qu’il n’y a pas moyen de faire marcher avec les scripts supplémentaires de SPIP ?
- goetsu
  
  Juin 2010
  
  c’est ce que propose porte_plume par exemple avec define(’PORTE_PLUME_PUBLIC’, false) ;
Répondre à ce message

« Précédent 1 ... 13 14 15 16 17 18 Suivant »

Ajouter un commentaire

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
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 apparaît.

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.

Qui êtes-vous ?

Nom [Se connecter]

Courriel (non publié)

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Texte de votre message

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Prévenez-moi de tous les nouveaux commentaires de cette discussion par email

Ajouter un document

Extensions autorisées : gif, jpg, png

Suivre les commentaires : |

Saisies

Introduction

Sommaire

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 des vérifications

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Pipeline

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 par date d’activité

Ajouter un commentaire

Saisies

Introduction

Sommaire

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 des vérifications

Support du multilinguisme

Options globales

Options pour le bouton de validation

Options pour la gestion des étapes multiples

Options techniques

Pipeline

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 par date d’activité

Ajouter un commentaire

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`