Saisies

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 pour les développeur⋅euses 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.

La balise #SAISIE

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

La balise a deux arguments obligatoires : le type du champ, et son nom HTML (attribut « name »). Toutes les autres options sont facultatives et servent à configurer le champ ; de ce fait, elles sont de la formes option=valeur.

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

Voici quelques exemples d’utilisation, pour comprendre l’approche.

Génère un simple champ texte, indiqué comme étant obligatoire :
#SAISIE{input, email, label=Votre courriel, obligatoire=oui}
 
Génère des boutons radios avec un choix "oui ou non" :
#SAISIE{oui_non, zanini, label=Tu veux ou tu veux pas ?}
 
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.

Consultez également :

-  La référence des options de chaque saisie

-  Un complément de doc avancée sur les saisies

Multilinguisme

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

Afficher les erreurs

Saisie gère nativement l’affichage des erreurs.

Si la fonction CVT verifier() retourne une erreur du même nom celle ci sera affichée entre le label et le champ.

  • Pour la saisie [(#SAISIE{input, annee, label=<:monplugin:annee:>})]
  • si verifier() retourne : $erreurs['annee'] = "Une erreur"
  • alors <span class="erreur_message">Une erreur</span> sera affichée juste avant l’input.

Enregistrer des tableaux

La norme HTML permet de gérer des réponses de formulaire sous la forme de tableau. Il est recommandé d’utiliser alors le formalisme suivant : tableau/variable.

  1. [(#SAISIE{input, annee/debut, label=<:monplugin:annee:>})]

Permettra de récupérer en PHP

_request('annee');
// array('debut' => 'valeur')

La forme HTML classique [(#SAISIE{input, annee\[debut\], label=<:monplugin:annee:>})] fonctionne aussi.


Attention, pour utiliser tout ce qui suit, vous devez installer aussi le plugin YAML.


Déclarer un formulaire CVT complet en PHP

Saisies augmente l’API CVT de SPIP avec une fonction …_saisies() afin de déclarer l’ensemble des champs d’un formulaire et leur vérification dans une unique syntaxe.

Grace à ce mécanisme, pour les cas les plus courants, les fonctions charger() et verifier() deviennent facultatives. Saisies s’occupera de tout suivant votre déclaration. Seule la fonction traiter() restera 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 pouvez le laisser totalement vide. Saisies s’occupera de générer le bon HTML complet.

Dans le PHP, au côté des autres fonctions, vous devez alors déclarer les saisies :

formulaires_monformulaire_saisies_dist() {
    $saisies = array();
 
    return $saisies;
}

Cette fonction doit retourner un tableau PHP contenant la liste de toutes vos saisies suivant un formalisme attendu.

Le tableau doit respecter les points suivant :

  • Chaque ligne du tableau d’ensemble est une saisie, elle-même étant décrite dans un tableau. L’ordre des éléments sera l’ordre des saisies.
    $saisies = array(
    	array(), // une saisie
    	array(), // une saisie
    	array(), // une saisie
    );
  • Chaque saisie individuelle est un tableau de la forme :
    array(
    	'saisie' => 'input',
    	'options' => array(
    		'nom' => 'nom',
    		'label' => 'Votre nom',
    		'size' => 50
    	),
    );
  • Les saisies qui acceptent des enfants (comme les fieldsets) les placent dans une clé « saisies » qui contiendra un tableau ayant la même structure que le tableau global :
    $un_fieldset = array(
    	'saisie' => 'fieldset',
    	'options' => array(
    		'nom' => 'mon_groupe',
    		'label' => 'Mon groupe de champ'
    	),
    	'saisies' => array(
    		array(), // une autre saisie
    		array(), // une autre saisie
    		array(), // etc
    	)
    );

Appliquer une vérification

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

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

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

Options globales

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

$saisies = array(
	'options' => array(
		// Changer l'intitulé du bouton final de validation
		'texte_submit' => 'Valider c’est gagné',
 
		// Transformer votre formulaire en multi-étapes
		// Chaque fieldset racine sera reconnu comme étant une étape !
		'etapes_activer' => true,
 
		// Changer l'intitulé du bouton suivant
		'etapes_suivant' => 'Suivantissime',
 
		// Changer l'intitulé du bouton précédent
		'etapes_precedent' => 'Previously on Lost',
	),
	array(), // une saisie
	array(), // une saisie
	array(), // une saisie
);

La balise #GENERER_SAISIES

Dans la plupart des cas vous n’avez pas à l’utiliser vous-même. Il se peut cependant que vous désiriez gérer malgré tout le squelette de votre formulaire.

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>
	#GENERER_SAISIES{#ENV{_saisies}}
</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].

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 :

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

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

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

Problème avec Xdebug

Si vous êtes développeur et que vous utilisez 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 modifier avec une variable. Vous devez donc ajouter cela dans votre configuration PHP/Xdebug :

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

Et hop, ça remarche.

Dernière modification de cette page le 17 mars 2019

Discussion

136 discussions

  • 2
    nikon33

    Bonjour

    MERCI de votre aide
    MERCI de votre attention

    Spip 3.0.19
    Processus de don pour une association

    Comme administrateur, au passage en backend de
    http://sourirepourlespoir.org/spipe

    Erreur
    Message
    Numéro 1
    Message Aucun squelette n’est disponible
    Squelette plugins/auto/saisies/v2.2.1/saisies/_base.html
    Boucle /
    Ligne 0

    NB :
    la désactivation réactivation des plugins
    (liés)
    Formidable 2.8.9
    Formulaire de paiement 1.0.4
    Saisies pour formulaires 2.2.1
    Formidable de participation Formidable 1.0.2
    Fusion de formulaire pour Formidable 1.0.1
    Spip Cycle2

    fait bien disparaitre et ré apparaitre l’écran d’erreur
    Aucun squelette n’est disponible

    Pouvez vous me donner une piste pour aller plus loin dans l’analyse sinon la solution

    MERCI

    • Cette erreur parle d’une saisie « montant » qui n’existe pas dans Saisies mais qui est propre au plugin de paiement. Donc je pense que tu devrais poser cette question aux gens qui maintiennent ce plugin. :)

    • nikon33

      pour RastaPopoulos

      Merci de votre réponse

      Juste en ajout au problème évoqué

      Cette alerte
      « Aucun squelette n’est disponible
      Squelette plugins/auto/saisies/v2.2.1/saisies/_base.html »
      n’est PAS
      présente sur la même base de donnée
      chez le même hébergeur
      avec la même version de php
      ... mais un site en Spip 3017

      je vais de ce pas voir du côté des plugins de paiements
      pour moi
      banque&paiements 2.32.1

      mais c’est peut être aussi un problème spip 3.0.17 spip 3.0.19

      MERCI de votre aide

    Répondre à ce message

  • Suggestion d’amélioration pour la saisie/date.html :
    -  pour pouvoir passer des paramètrages au inc-dateur (standard de spip 3),
    il faudrait en fin de saisie/date.html, rajouter un paramètre ,env
    à la ligne : [(#INCLURE{fond=formulaires/dateur/inc-dateur, env, heure_pas=#ENV{heure_pas,30}})]], ou au moins transmettre une chaine/array d’options : je l’ai fait dans une surcharge perso mais..
    Est-ce un problème au niveau du cache de cette noisette ?

    Merci
    YannX

    PS : exemple d’utilisation : transmettre un « yearRange: 'c-100:c+1',  » (pour pouvoir facilement saisir l’année de naissance) ou un format de date de saisie en fonction du langage !

    Répondre à ce message

  • 2

    Bonjour,
    J’ai besoin de créer une nouvelle saisie spéciale qui n’a pas à accéder à un champ de la bdd (comme fieldset) mais qui doit par contre récupérer une variable dans l environnement de la page (id_auteur), et.... j’y arrive pas....
    J ai créé mon couple de fichier html et yaml, je me dis que depuis le yaml faut p’etre passer un paramètre au html (comme pour les noisettes du noizetier) ?
    J’utilise cette saisie avec les champs extra depuis l interface extra (je ne sais si ca change quelque chose)...
    amicalement
    triton

    • Mmmh je ne sais plus si c’est possible déjà. Ça me dit quelque chose que quelque part dans le code (ouais c’est hyper vague) il y a un endroit qui teste si on doit passer tout l’environnement ou seulement une partie précise nécessaire. Mais de tête je ne me rappelle plus des conditions.

      Je dis ça, c’est pour l’API PHP où on génère pleins de saisies à partir d’un tableau complet. Quand c’est saisie par saisie avec la balise unitaire, là je sais pas (sûrement juste ajoute « , env » dans les params).

      Pas eu le temps de re-fouiller le code pour l’instant, désolé. :(

    • J ai contourné le pb en dupliquant une saisie de type input que je positionne sur mon champ id_auteur (en lecture seul) et a partir de cet id_auteur je vais chercher mes données dans ma saisie...
      Je vais quand même essayer de lire le code voir si je trouve...
      merci pour la reponse
      amicalement
      triton

    Répondre à ce message

  • 1

    En voulant ajouter un nouveau champ (après en avoir ajouté d’autres sans pb) je rencontre cette erreur : Fatal error : Maximum execution time of 120 seconds exceeded in /www/plugins/auto/saisies/v1.40.7/inc/saisies.php on line 132

    Pourriez vous m’aider ??

    • Si tu ajoutes des champs, c’est à priori que tu parles du plugin champs extras, qui lui même est utilisateur du plugin saisies. M’est avis que tu devrait plutôt poser la question dans le forum de ce plugin, si ce n’est pas déjà fait. :)

    Répondre à ce message

  • Bonjour,
    Je débute dans l’utilisation des formulaires pour mettre en place une procédure de dons sur le site http://www.cubacoop.org/
    J’utilise les plugins ;
    Formidable 2,8,0
    Saisies pour formulaires 1.42.1
    YAML1.5.2
    Transaction 0.3.1
    Mes premiers test semblent satisfaisants mais je ne comprend pas pourquoi après validation de la saisie d’une entrée dans le formulaire, le message de retour est affiché 6 fois au lieu d’une.
    Merci de me dire où je peux corriger cet affichage multiple.

    le formulaire peut être testé ici

    Répondre à ce message

  • 17

    Bonjour,
    je configure un formulaire avec Formidable avec ces versions : [ Spip 3.0.16 / Formidable 2.5.14 / Saisies 1.40.4 ].
    La fonction pliable d’un groupe de champs fonctionne très bien en partie privée, mais pas du tout sur la partie publique.
    J’ai fait les vérifications suivantes :

    • activer et désactiver les différentes Compatibilité Microsoft Internet Explorer ;
    • activer la norme à suivre HTML 4 ou HTML 5 ;
    • vérifier le bon chargement du fichier javascript saisies.js sur la page devant afficher le formulaire.

    Rien n’y fait, mon groupe de champs s’affiche déplié et ne se replie pas au clic.

    • ERRATUM. Il s’agit de la version 3.0.5 de Spip. Et non pas la 3.0.16.

    • Ben si ça marche dans le privé et pas dans le site c’est que dans le site le JS n’est pas ajouté à priori. Ou alors qu’il y a une erreur JS en amont de l’activation du pliage. Regarde déjà dans le code (sans compresser le JS évidemment) si le fichier JS de Saisies est bien inséré dans ton site. Et ensuite regarde dans la console de Firefox s’il y a des erreurs JS.

    • Merci. Problème résolu.

      C’est le script menuder.js du Plugin Menuder pour MSIE qui me faisait planter.
      $ is not a function
      Ligne 19 $(’.menuder ul’)

      En désactivant le plugin, tout rentre dans l’ordre. Et je n’ai pas besoin de ce plugin.

    • Bonjour RastaPopoulos,
      quand le JS n’est pas ajouté, ça peut être du à quoi ? Comment remédier à ça ?
      Est-ce que je devrais voir si un autre plugin bloque le script comme chez niconito ?
      d’avance merci pour toute piste
      joz

    • C’est pas ajouté ou tu as une erreur JS en amont ? Tu peux voir ça dans la console javascript de Firefox quand tu recharges la page. Il faut regarder si le script est bien dans le HTML aussi, soit tout seul soit concaténé si la compression est activé (mais au début du fichier concaténé il y a la liste en commentaire).

    • hmm, je t’avoue que je ne sais même pas comment le script en question dois s’appeler.. du coup comment vérifier s’il est présent ?
      je ne trouve rien qui s’appelle ’saisie’ ou ’plie’ en tout cas
      http://vivre-ensemble.be/Bon-de-commande-2014
      désolé pour mon ignorance..
      joz

    • Avant le script, je te demandais en priorité de regarder d’abord s’il y avait une erreur javascript, comme pour niconito. Ce qui est effectivement le cas sur ton URL : « ReferenceError : trackPage is not defined » dans la console du navigateur (F12 sur Firefox, onglet Console).

      Je ne sais pas ce que c’est, pas un truc de SPIP en tout cas.

    • merci d’avoir jetté un coup d’oeuil !
      j’ai nettoyé l’erreur (trace d’un plugin installé dans le passé), mais le pliable reste toujours non-fonctionnel..
      ai je oublié d’autre chose ?

    • T’aurais pas un plugin gredin qui utilise le pipeline « affichage_final » et qui OUBLIE de renvoyer le flux à la fin (et donc les plugins suivants n’ont pas le bon truc) ?

      Comme d’hab, dans tous les cas, pour tester un pugin, il faut d’abord désactiver absolument tous les plugins non-nécessaires à son fonctionnement. Sinon ça fait trop de combinaisons possibles.

    • Bonjour,
      c’est encore moi...

      Je n’ai pas de plugin qui s’appelle gredin et je ne vois rien de se nom dans les erreurs, ni nulle part dans mon site (squelettes, cache.. nulle part)...

      En local j’ai désactivé tout les plugins, sauf ceux nécessaire pour formidable + j’ai enlevé mes squelettes. Mais le pliable ne fonctionne toujours pas
       :(

      Aurais-tu encore une autre petite piste à suivre pour moi ?
      d’avance merci !
      joz

    • Haha : http://fr.wiktionary.org/wiki/gredin
      Un plugin qui ferait des saletés donc. :)

      Actuellement tout ce qu’insère normalement le plugin Saisies grâce au pipeline « affichage_final » ne se fait pas DU TOUT sur ton site. Donc il y a un problème en amont. Tu peux par exemple modifier directement le code du plugin pour débuguer, et dans saisies_pipelines.php, dans la fonction « affichage_final », tu fais n’importe quoi, genre echo "PROUT"; die(); pour voir si déjà SPIP rentre bien dans la fonction. Si ce n’est pas le cas c’est qu’il y a un autre plugin en amont qui gêne.

    • hihi
      chouette, j’ai appris un mot de plus en français :)

      j’ai mis ta ligne echo dans mon saisies_pipelines.php, mais le site ne prout pas..

      voici les plugins actuellement activés (tous à jour, SPIP 3.0.17 [21515] ) :
      API
      Facteur
      Formidable
      Saisies
      SPIP Bonux
      YAML

      ...
      joz

    • Dans ton code source, il n’y a a aucun endroit le commentaire HTML « inserer_saisie_editer » alors que c’est sur cette chaîne que ce base le test pour décider s’il faut insérer ou pas des choses de Saisies.

      C’est normalement ajouté par chaque saisie dans ce fichier de base :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/_base.html

      L’aurais tu surchargé dans ton squelette ?

    • Bonjour,
      j’ai re-essayé en mettant le echo PROUT au debut de affichage_final (avant je l’avais mis à la fin après return $flux ;), et maintenant ça marche, ça prout sans faute : )

      Egalement avec mes squelettes et avec tout mes plugins activés.

      Mais pour rendre le pliable fonctionnel, comment ce prout peut m’aider ?

      Bien à toi

    • Je t’ai déjà donné une autre piste dans mon message précédent.

      Le PROUT signifie que ça passe bien dans cette fonction, c’était le but de cette vérification. Mais comme je le disais précédemment, dans cette fonction on fait un test sur l’existence de la chaîne « inserer_saisie_editer » dans le HTML final, or elle n’apparait nulle part chez toi !

      Alors que cette chaîne est normalement insérée pour TOUTES les saisies quelles qu’elles soient (donc autant d’apparition de cette chaîne que de saisie dans la page).

      Tu dois avoir une surcharger de « _base.html » quelque part, un truc dans ce genre, qui supprime ce morceau.

    • Merci pour ta patience.. sorry pour ma lenteur.

      Quand je change dans saisies_pipelines.php
      la ligne 17

              if (($p = strpos($flux,"<!--!inserer_saisie_editer-->"))!==false){

      en
              if (($p = strpos($flux,"<!--!inserer_saisie_editer-->"))==false){
      (donc sans !), le pliable fonctionne.

      ...
      J’ai installé un spip3.0.17 fraiche + avec formidable et ses plugins dépendant, sans mes squelettes, mais ma base de données. Et le pliable n’y marche pas !
      Donc si quelque chose surcharge la fonction, est-ce que ce serai dans ma base ? Est-ce que ça serai possible ?
      Si oui, pourrais-tu me donner une chaîne de caractères à chercher dans ma base qui pourrait être responsable d’un tel bloquage ?
      Pour trouver le gredin ..

    • Il n’y a absolument rien à changer dans la fonction PHP, c’est ton HTML qui ne va pas, qui ne contient pas le commentaire HTML avec la chaîne recherchée.

      Comme dit précédemment, c’est dans ce squelette :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/_base.html

      Regarde son code, tu vois que ce commentaire est bien là. Donc si tu ne l’as pas chez toi, c’est soit que tu as une surcharge perso de ce squelette, soit que c’est directement dans ton plugin Saisies que le fichier n’est pas bon.

      Ouvre donc plugins/saisies/saisies/_base.html et regarde dedans pour voir.
      Sinon fait « var_mode=inclure » dans l’URL, pour voir les blocs inclus, et donc voir si ya une surcharge.

    Répondre à ce message

  • 7

    Bonjour,

    J’ai un soucis lorsque je charge un formulaire dans une modalbox depuis l’espace privé

    mon js :

    $(".mon_selecteur").live('click',function(e){
                e.preventDefault();
                $.fn.mediabox({
                    href:'../spip.php?page=formulaires/modalbox/mon_squelette',
                    width:'600px',
                    height:'auto',
                    overlayClose:false});
            });

    ma noisette ’mon_squelette’

    #HTTP_HEADER{Content-Type: text/html; charset=#CHARSET}
    #CACHE{0}
    <div class="ajax">
        [(#SESSION{statut}|=={0minirezo}|oui)
            [(#FORMULAIRE_AVEC_DES_BALISES_SAISIE)]
        ]
    </div>

    Le formulaire s’affiche sans problème et fontionne mais :
    Dans les logs firebug j’ai des 404 not found.

    En regardant un peu le code du plugin et plus particulièrement la fonction saisie_affichage_final je m’aperçois que la fonction generer_url_public genere des liens de script et css de la forme :

    http://mon.domaine.com/ecrire/plugins-dist/jquery_ui/css/jquery.ui.theme.css

    Ce qui m’amène à vous poser plusieurs question :

    Quel est la meilleur façon d’afficher un formulaire dans une modalbox ?
    Est il possible de court-circuiter affichage_final sur une noisette appeler via /spip.php ?page=
    Est-il possible de dire à saisie qu’on ne veut pas de qu’il charge de script ?

    • J’ai trouvé !

      Je pense que la meilleur solution c’est de créer une page vierge dans l’espace privé en utilisant exec.

      1°) Creer un repertoire exec à la racine du plugin

      2°) Dans le repertoire exec creer un fichier « script.php »

      <?php
       
      if (!defined("_ECRIRE_INC_VERSION")) return;
       
      function exec_script_dist(){
       
          # Recuperer le squelette 
          echo recuperer_fond(
              'formulaires/modalbox/mon_squelette',
              $contexte = array(), 
              $options = array('ajax' => 'true')
          );
      }
      ?>

      3°) Puis dans l’appel pour modalbox mettre l’URL du prive qui va bien :

          $(".mon_selecteur").live('click',function(e){
          e.preventDefault();
          $.fn.mediabox({
          href:'/ecrire/?exec=script', //chargement ajax du script espace privé
          width:'600px',
          height:'auto',
          overlayClose:false});
          });

      Et ça roule :D Merci spip !

    • Wow, c’est moche. :D

      Déjà ça fait des années qu’on ne fait plus de exec en PHP…
      Ensuite page=truc/sous/dossier, ça ne marche que pour les admins complets.

      Il faut que ce soit une page accessible pour pouvoir y accéder, donc si c’est avec #URL_PAGE, ça doit être un squelette à la racine (à la racine de ce qu’on veut, squelettes, plugins, etc, mais à la racine d’un dossier du Path).

      Quand on utilise un squelette de type Z (et l’admin de SPIP 3 est comme ça), on peut ajouter le paramètre « var_zajax=nom du bloc » dans l’URL, et ça va alors chercher uniquement ce bloc Z pour la page demandée. Tu peux donc parfaitement construire une vraie page d’admin avec le formulaire ET l’interface autour, il suffit de faire un squelette /prive/squelettes/contenu/truc.html. Et ensuite quand tu l’appelles, tu vas chercher #URL_ECRIRE{truc, var_zajax=contenu} et ça va te donner que le bloc principal où il y aura ton formulaire.

      Mais sinon, à part ça, je vois pas trop le rapport avec Saisies (qui n’insère la CSS de UI que s’il y a une saisie de date de trouvée).

    • Ah oui c’est si moche que ça ? :D

      J’avais bien utiliser le « var_zajax=contenu » mais les retours cvt ’ajaxés’ reviennent sur l’URL d’origine du bloc contenu.

      En utilisant href :’/ecrire/ ?exec=article_edit&new=oui&var_zajax=contenu’, je charge bien mon formulaire de creation d’article, mais si je valide (je ne selectionne pas de rubrique par ex) le retour d’erreur redirige sur la page d’origine /ecrire/ ?exec=article_edit&new=oui

    • Mais il faut que ton formulaire soi bien entouré de div class=« ajax » dans le squelette, pour qu’il soit lui-même validé en ajax à chaque fois.

    • Ca marche Merci !

    • juste une remarque.

      Popin dans l’espace privé : Un lien vers une page de l’espace privé avec une classe .popin provoque l’ouverture d’une popin qui contient le coeur de la page pointée (bloc contenu/). Le lien conserve sa capacité à être ouvert dans un autre onglet via clic droit et la page complète est affichée dans ce cas.

      Donc en fait, juste avec la class .popin sur un <a href ds l’espce privé suffit ...

      ça n’a pas de rapport avec saisies mais un peu avec mon problème de départ

    • Ah je ne me souvenais plus de ce point, merci du rappel !

    Répondre à ce message

  • Bonjour,
    et merci pour ce plugin qui simplifie bien les choses !

    En évolution, sera t-il possible d’uploader un document, une image par exemple ? Ce serait génial !

    Répondre à ce message

  • 2

    Bonjour,

    J’aimerais savoir quelle format doit avoir la colonne d’une table sql qui reçoit les données de saisie ’checkbox’ ou cases à cocher ?

    Spip 3.0.16 et Saisies pour formulaires 1.40.4 - stable...

    Merci d’avance de votre aide !

    • Une table SQL ne reçoit pas le contenu d’une saisie HTML. C’est traité par CVT avant. Or les champs HTML checkbox, select multiple, et certains autres, génèrent au serveur (donc ici PHP) des tableaux (array PHP donc).

      À chacun⋅e d’en faire ce qu’ille veut avant d’envoyer dans la base. Ça peut être dans une table dédié à ces choix (je sais pas, je ne connais pas le contexte moi), ou bien basiquement une sérialisation du tableau (serialize()) donc une chaîne de caractère (donc un champ SQL « text » à priori).

    • Merci de tes explications.

      Je vais approfondir le sujet en me basant sont ta courte, mais ô combien utile, réponse.

      Bien à toi !

    Répondre à ce message

  • 4

    J’utilise plusieurs champs date dans mon formulaire à l’aide de saisie.
    Cependant le code suivant ne me permet pas d’avoir le calendrier au clic sur l’icone :

    [(#SAISIE{date, date_deb})]
    [(#SAISIE{date, date_fin})]

    car l’inclusion du « formulaires/dateur/inc-dateur » est double et empêche le bon affichage de celui-ci.
    Pour que cela fonctionne, je dois faire :

    [(#SAISIE{date, date_deb})]
    [(#SAISIE{input, date_fin, class=date})]

    Est-ce normal ?

    Merci

    • Non ce n’est pas normal, mais il faudrait corriger le inc-dateur du noyau qui ne devrait pas insérer deux fois le même JS si on l’appelle plusieurs fois. Il faudrait un test avec une variable globale ou un truc comme ça pour savoir qu’il a déjà été appelé avant.

    • brain_damage

      bonjour,

      Comment faites vous pour utiliser le date_picker sur un champ date et enregistrer au format ’date’ ou ’datetime’ ?

      le picker complete le champ en JJ/MM/AAAA et mysql veut du AAAA-MM-JJ

      ya bien la solution
      [(#SAISIEdate_jour_mois_annee, datet, obligatoire=oui,
      label=<:date :>
      )]

      mais si je veux un date_picker je ne comprends pas comment convertir automatiquement le format.

      Est ce un réglage php ou une options dans saisies ?

    • Avec le plugin Vérifier, il faut utiliser la vérification « date » et activer la normalisation SQL.
      Sans le plugin Vérifier, on peut faire la même chose à la mano dans la fonction verifier() de CVT.

    • brain_damage

      Merci Beaucoup !

      Va falloir que je me décide alors :|

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

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

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.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom