Référence des saisies

Discussions par date d’activité

39 discussions

• 7

  

  baloo

  il y a 3 mois

  bonjour
  y a t-il un moyen de permettre de classer les rubriques ou les articles sélectionnés avec selecteur_rubrique_article ou selecteur_article en restant dans le formulaire ?

  • 

    RastaPopoulos

    il y a 3 mois

    Il me semble que c’est le cas non ? Quand ya le choix multiple, on peut drag n drop la sélection pour changer l’ordre, et ça change alors le tableau PHP final qu’on reçoit de mémoire (c’est exactement comme ça que Polyhiérarchie sépare le premier de la liste des autres, en mettant le premier en vraie rubrique et les autres en rubrique secondaire).

  • 

    baloo

    il y a 3 mois

    j’ai par exemple la saisie suivante
    array(
    ’saisie’ => ’selecteur_article’,
    ’options’ => array(
    ’nom’ => ’sel1_art’,
    ’multiple’ => ’oui’,
    ’label’ => ’<:paramsite:champ_article_label :>’,
    ’explication’ => ’<:paramsite:champ_article_explication :>’,
    ’defaut’ => ’’,

    )
    ),

    et je ne vois pas ou je peux faire un drag and drop lorsque l’on saisie des articles avant ou aprés fermer

  • 

    baloo

    il y a 3 mois

    Plus exactement le drag and drop ne fonctionne pas.
    Par contre si j active le plugin polyhiersrchie son drag and drop fonctionne bien mais il n utilise pas le même mécanisme de saisie.

  • 

    RastaPopoulos

    il y a 3 mois

    Pourtant si ça utilise bien le même mécanisme : uniquement redirection vers les sélecteurs rubriques et articles du core : https://git.spip.net/spip-contrib-extensions/polyhierarchie/src/branch/master/formulaires/inc-selecteur-parents.html

    Et dans les deux cas ya bien le JS inséré :
    https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/selecteur/articles.html#L2

  • 

    baloo

    il y a 2 mois

    après de nombreux test j’ai vue que si plusieurs selecteur_rubrique et/ou selecteur_rubrique_article multiple étaient présent dans le formulaire .... seul le premier était dragable en particulier avec afficher_si

    'saisies' =>  array(          
                    array(
                            'saisie' => 'selection',
                            'options' => array(
                                    'nom' => 'sel1_choix',
                                    'label' => '<:paramsite:champ_choix_label:>',
                                    'explication' => '<:paramsite:champ_choix_explication:>',
                                    'defaut' => 'articles',
                                    'cacher_option_intro' => 'oui',
                                    'data' => array(
                                        'art' => 'articles',
                                            'rub' => 'rubriques',
                                            'artrub' => 'articles et rubriques',
                                                                                    )
                                    )
                            ),        
                                                    
             
                    array(
                            'saisie' => 'selecteur_rubrique_article',
                            'options' => array(
                                    'nom' => 'sel1_rubart',
                                    'multiple' => 'oui',
                                    'afficher_si' => '@sel1_choix@  == "artrub"'
                                    
                                    )
                            ),
                            
                    array(
                            'saisie' => 'selecteur_rubrique',
                            'options' => array(
                                    'nom' => 'sel1_rub',
                                    'multiple' => 'oui',
                                    'label' => '<:paramsite:champ_rubrique_label:>',
                                    'explication' => '<:paramsite:champ_rubrique_explication:>',
                                    'defaut' => '',
                                    'afficher_si' => '@sel1_choix@  == "rub"'
                                    )
                            ),

    ou meme

    $saisies = array(	   //unesaisie		
    		
    	   
    			
    		
    	$general_fieldset = array( // ONGLET GENERAL
    		'saisie' => 'fieldset',
    		'options' => array(
    			'nom' => 'general',
    			'label' => 'général',
    			
    			),
    		
    		'saisies' =>  array(	   //unesaisie
    		
    		
    		array(
    			'saisie' => 'selecteur_rubrique',
    			'options' => array(
    				'nom' => 'rub',
    				'label' => 'rubrique',
    				'multiple' =>'oui',
    								
    				
    				)
    			),
    		array(
    			'saisie' => 'selecteur_rubrique',
    			'options' => array(
    				'nom' => 'rub2',
    				'label' => 'rubrique',
    				'multiple' =>'oui',
    								
    				
    				)
    			),
    		array(
    			'saisie' => 'selecteur_article',
    			'options' => array(
    				'nom' => 'art',
    				'multiple' => 'non',
    				'label' => 'article',
    				
    				
    				
    				
    				)
    			),
    		
    	
    		
    		)
    	)
    	);
    	
    return $saisies;

  • 

    baloo

    il y a 2 mois

    pour selecteur_article cela fonctionne si j’ajoute ( juste en test) dans prive/formulaires/selecteur/articles de spip le code suivantqui existe dans le fichier rubriques présent au même endroit

    
    [(#ENV{sortable,non}|=={oui}|oui)
    <script type='text/javascript'>
    
    (function(){
    
    	const picked_sorter = () => { 
    
    		new Sortable(document.querySelector("ul.item_picked"));
    
    	};
    
    	if (typeof Sortable === "undefined") {
    
    		jQuery.getScript('[(#CHEMIN{prive/javascript/Sortable.min.js}|timestamp)]').done(picked_sorter);
    
    	} else {
    
    		picked_sorter();
    
    	}
    
    })();
    
    </script>
    ]

  • 

    baloo

    il y a 2 mois

    Bon je me suis un peu embrouille dans mes explications en résume :
    si il y a plusieurs selecteur_article ou et selecteur_rubrique et ou selecteur_rubrique_article dans le meme formulaire de l’espace prive ... seul le premier selecteur est dragable.

    par ex : selecteur_article ,selecteur_rubrique seul article est dragable.
    selecteur_rubrique selecteur_ article c’est rubrique qui est dragable
    selecteurs_articles selecteur_article : seul le premier est dragable
    selecteur_rubrique_article .selecteur_article : seul rubrique_article est dragable..

  Répondre à ce message

• 2

  

  baloo

  il y a 5 mois

  comment peut on ne voir que les articles « publies » avec saisie ?
  en spip 4.2.6 saisie 4.7.1 le code suivant me donne les articles publies et non publies
  array(
  ’saisie’ => ’selecteur_article’,
  ’options’ => array(
  ’nom’ => ’sel1_art’,
  ’multiple’ => ’oui’,
  ’label’ => ’<:paramsite:champ_article_label :>’,
  ’explication’ => ’<:paramsite:champ_article_explication :>’,
  ’defaut’ => ’’,

  )
  ),
  merci

  • 

    RastaPopoulos

    il y a 5 mois

    Je ne crois pas que ce soit possible avec le sélecteur du core, qui est fait pour faire des interfaces dans l’admin : https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies/selecteur_article.html#L38

    Il n’y a aucun « env » passé à l’inclusion, donc on ne peut passer aucun environnement supplémentaire au sélecteur du core à qui on délègue et qui aurait pu avoir un {statut?} éventuellement dans la boucle (et de toute façon le picker en ajax ne prévoit pas de passer ça).

  • 

    baloo

    il y a 2 mois

    cela semble fonctionner en ajoutant statut=publie dans selecteur_article
    on ne sélectionne que les articles publiés... car dans prive/formulaires/ selecteurs / articles la boucle contient le champ statut.

    <BOUCLE_art(ARTICLES){statut?}{tout}{id_article}>#SET{id_rubrique,#ID_RUBRIQUE}</BOUCLE_art>

    avec un

     statut=#ENV{statut,""} 

    cela serait peut être généralisable

    [(#INCLURE{fond=formulaires/selecteur/articles,
    	selected=#GET{val},
    	name=#ENV{nom},
    	afficher_langue=#ENV{afficher_langue,''},
    	filtrer_langue_article=#GET{filtrer_langue_article,''},
    	select=[(#ENV{multiple}|?{0,1})],
    	sortable=[(#ENV{multiple}|?{oui,non})],
    	tri==[(#ENV{multiple}|?{0,1})],
    	limite_branche=#ENV{limite_branche,''},
    	rubriques=0,
    	statut=publie})]

  Répondre à ce message

• 7

  

  touti

  Janvier 2022

  Bonjour,
  une question sur l’affichage visuel des champs,
  on peut mettre deux champs de saisies en php dans un fieldset, ça fonctionne bien.
  Mais comment ajouter une class spécifique englobant ces deux champs.
  Avec bootstrap (ou d’autres framework css), si le div class editer-groupe du fieldset pouvait prendre la class row, les deux champs avec un col-6 se rangeraient côte à côte gentiment.
  Voici mon code

  	// Champ tel_fixe
  	$fieldset_tel_fixe[] = array(
  		'saisie' => 'input',
  		'options' => array(
  			'li_class' => 'form-group col-md-6', 
  			'class' => 'form-control', 
  			'nom' => 'tel_fixe',
  			'label' => _T('contact:champ_tel_fixe_label'),
  			'obligatoire' => 'oui',
  		),
  	);
  	
  	// Champ tel_fixe
  	$fieldset_tel_fixe[] = array(
  		'saisie' => 'case',
  		'options' => array(
  			'li_class' => 'form-group col-md-6', 
  			'class' => 'form-control', 
  			'nom' => 'tel_fixe_public',
  			'label' => _T('contact:champ_tel_fixe_label'),
  			'label_case' => 'rendre ce numéro public',
  		),
  	);
  	
  	$saisies[] = array(
  					'saisie' => 'fieldset',
  					'options' => array(
  						'nom' => 'telephone_fixe',
  						'class' => 'canemarchepas ici row',
  						'label' => _T('contacts:telephone_fixe'),
  						'conteneur_class' => 'fieldset_tel_fixe row',
  					),
  					'saisies' => $fieldset_tel_fixe
  	);

  Et belle année. pas trop môche en tout cas.
  Bisoux

  • 

    RastaPopoulos

    Janvier 2022

    Hello Touti, bonne année
    voilà une PR qui devrait te plaire et qu’il ne reste « plus que » à faire avancer jusqu’au bout (désolé de la longueur, faut justement finir de se mettre d’accord après tous ces débats) :)
    https://git.spip.net/spip-contrib-extensions/saisies/pulls/98

  • 

    touti

    Janvier 2022

    Hello,
    merci pour ta rapidité et la bonne année !
    pas fini de lire le fil, mais amha il y a confusion entre la possibilité de mettre une class du fait de la codeuse et le choix de cette class. Et là, je ne me prononce pas du tout puisque je suggère que cela dépende des souhaits de celle qui l’utilise.
    En fait ce serait plus clair de décider ou ajouter « class_conteneur » ou « class_li » ou « class_truc » pour toutes les saisies avec un niveau de profondeur par rapport au champ ? Nolosé, mais je m’abonne au fil GIT !

    ++

  • 

    RastaPopoulos

    Janvier 2022

    Il n’est pas prévu de personnaliser les classes à chaque niveau. Enfin si ça devait se faire ça serait propre à chaque saisie, chacun pouvant produire absolument n’importe quoi comme HTML. Mais vraiment, on va pas s’amuser à ajouter un champ de perso CSS pour chaque sous-niveau. En effet, la perso CSS sert à cibler tel *champ* précis, mais ensuite on utilise tout simplement la cascade pour styler le reste.

    Pour appliquer row il faut plutôt utiliser Bootstrap *en SCSS*, et donc pouvoir hériter des styles de row à n’importe quel sous-endroit d’une cascade de classe.

    Cependant, la PR que je pointais c’était pour une raison plus précise : ce n’est pas du tout en rapport avec le fait de pouvoir personnaliser des classes, mais plus précisément car tu parlais de vouloir mettre « en ligne » certains champs d’un groupe. Et justement cette PR a pour but que le plugin fournisse d’office une saisie officielle groupant les champs intérieurs « en ligne » par défaut, sans rien avoir à connaitre des CSS. Faut juste finir de se mettre d’accord sur la nomenclature et la limitation de ce que ça doit permettre. :)

  • 

    touti

    Janvier 2022

    Bonjour,
    Petit préambule : j’utilise CSS depuis quelques années et je connais SCSS, dont j’ai produit le plugin SPIP. Je suppose que je sais donc de quoi je parle, je sais parfaitement personnaliser les saisies, les CSS ou surcharger les class SCSS de Bootstrap. Ici, j’essaye d’appréhender les choses de façon générique et pour toutes personnes débutantes,.

    Tu dis

    Il n’est pas prévu de personnaliser les classes à chaque niveau.

    Uhuh, ça n’existe pas comme réponse, le principe est toujours d’anticiper, sinon dans ce cas, on ne fait rien, je ne proposer rien, et on n’écoute personne.

    Enfin si ça devait se faire ça serait propre à chaque saisie, chacun pouvant produire absolument n’importe quoi comme HTML

    Hum, je ne propose pas du tout de faire de la bouillie personnelle. Saisies concerne SPIP, beaucoup de plugins dont formidable et les classes actuelles sont des classes SPIP qu’il n’est pas facile de contrôler,
    Et je suis toujours dans l’optique d’offrir quelque chose de simple et compréhensible et ne pas avoir à tambouiller en scss.
    Donc anticiper et penser à une hiérarchie sémantique générique avec possibilités de baliser ces class ne serait-ce que par niveau (#css_pour_premier_conteneur / #css_pour_deuxieme_conteneur / #css_pour_dernier_conteneur) serait un plus. Un peu comme le #DIV a remplacé le <li> saisies offrirait un jeu avec des caractèristiques CSS facilement surchargeable.
    #css_pour_premier_conteneur => .editer-groupe

    Mais vraiment, on va pas s’amuser à ajouter un champ de perso CSS pour chaque sous-niveau.

    En établissant quelques principes, on aurait la même chose qu’un fichier de lang, un seul tableau avec les champs voulus … et surchargeable soit par le tableau soit dans la saisie elle même. Donc, adoption de différents framework possible. J’dis ça, j’dis rien.

    En effet, la perso CSS sert à cibler tel *champ* précis, mais ensuite on utilise tout simplement la cascade pour styler le reste.

    Oui, c’est tout le principe des class CSS.

    Pour appliquer row il faut plutôt utiliser Bootstrap *en SCSS*, et donc pouvoir hériter des styles de row à n’importe quel sous-endroit d’une cascade de classe.

    Oui, c’est tout le principe des class SCSS mais ce n’est pas facilement applicable en l’état avec les saisies, (à moins de faire de l’horlogerie), qui comme dans mon exemple ne dispose pas de cette possibilité d’insérer une class.

    Cependant, la PR que je pointais c’était pour une raison plus précise : ce n’est pas du tout en rapport avec le fait de pouvoir personnaliser des classes,

    Tu confonds pas insérer des class et les personnaliser ?

    … mais plus précisément car tu parlais de vouloir mettre « en ligne » certains champs d’un groupe.

    Donc de pouvoir insérer une class, ce qu’il n’est pas possible de faire en l’état.

    Et justement cette PR a pour but que le plugin fournisse d’office une saisie officielle groupant les champs intérieurs « en ligne » par défaut, sans rien avoir à connaitre des CSS. Faut juste finir de se mettre d’accord sur la nomenclature et la limitation de ce que ça doit permettre. :)

    Merci pour le résumé officiel, je comprends, mais je vais pas être désolée de trouver ça limité et pas générique et d’avoir d’autres idées :)

  • 

    Maïeul

    Janvier 2022

    J’ai essayé de comprendre la conversation mais je suis pas sur d’avoir tout capté. Dis moi si je me trompe tout.

    Il me semble qu’il y a deux besoins différents exprimés :
    -  pouvoir regrouper des saisies sans passer par un fieldset : ça c’est la PR ouverte, avec encore des questions de convention à trancher
    -  pouvoir insérer automatiquement une classe selon le niveau de profondeur ? Ou bien c’est encore autre chose ? Si j’ai bien compris ce besoin, il me semble que l’on pourrait effectivement imaginer cela comme une option globale du formulaire, et se débrouiller pour calculer la profondeur par simple augmentation d’un co.pteur chaque fois qu’on passe à une sous saisie

  • 

    Maïeul

    Janvier 2022

    En fait ce serait plus clair de décider ou ajouter « class_conteneur » ou « class_li » ou « class_truc » pour toutes les saisies avec un niveau de profondeur par rapport au champ ?

    C’est cette phrase que je ne comprend pas tout à fait.

  • 

    touti

    Janvier 2022

    Bonjour Maïeul,
    j’essayerai d’expliciter ces idées dès que j’ai le temps de faire des essais et vous remonter les tests.
    Pas d’urgence :)
    Bonne journée

  Répondre à ce message

• 3

  

  paidge

  Décembre 2019

  Bonjour,
  Je suis en train de développer un thème et j’aimerais que, dans le backend, les administrateurs puissent uploader une image. Grâce au plugin SAISIES POUR FORMULAIRES, j’aimerais intégrer un INPUT type=« file » mais je n’y arrive pas. Dans la documentation ici présente, je vois pourtant le type de SAISIE qui s’appelle FICHIER mais SPIP me dit qu’aucun squelette n’est existant...

  • 

    Maïeul

    Décembre 2019

    La saisie de type fichier est particulière. Elle est fournie avec CVT upload, et pas directement avec le plugin saisies.

    Par ailleurs, cvt upload ne fournit pas de traitement à posteriori. Donc je vous invite à lire la documentation

    https://contrib.spip.net/CVT-Upload

  • 

    paidge

    Décembre 2019

    Bonjour et merci pour cette réponse qui confirme ce que j’en avais déduit suite à mes recherches. Je ne voulais pas installer un énième plugin mais si il le faut, je ferai des essais.

  • 

    paidge

    Octobre 2021

    En me documentant, j’ai l’impression que c’est le plugin BIGUP qui est intégré dans plugins-dist et qui remplace CVT-upload. D’après ce lien, il y aurait une #SAISIEbigup mais je ne trouve pas de trace ici :/

  Répondre à ce message

• 15

  

  ygornet

  Septembre 2017

  salut

  j’ai essayé cette syntaxe, sans succès, dans la page html d’un formulaire cvt :

  [(#SAISIE{input, pratique_autre,
            affiche_si = '@pratique@ == "Autre"',
            label=<:label_autre:>})] 

  -  parceque le javascript n’est pas chargé ?
  -  parceque ce n’est pas la bonne syntaxe ?

  je suis perdu
  bien à vous, Yanic

  • 

    Maïeul

    Septembre 2017

    ce serait pas afficher_si plutôt que affiche_si ?

  • 

    ygornet

    Septembre 2017

    exact, afficher_si

    mais ça ne suffit pas à le faire fonctionner

  • 

    Maïeul

    Septembre 2017

    je sais pas trop. Faudrait que je vois in situ pour saisir le problème (peut être). Envoi moi un mail on peut en discuter en privé.

  • 

    JLuc

    Mars 2018

    Ce n’est pas @pratique@ qu’il faut utiliser dans le afficher_si, mais le nom technique de la saisie (celui qui apparaît dans la colonne de gauche de formidable)
    un nom du genre @selection_2@ ou @case_3@

  • 

    Maïeul

    Mars 2018

    @JLuc : ce que tu dis vaut pour formidahble qui crée ainsi ses noms de champs. Pas sûr que valable pour des saisies que tu fais à la main

  • 

    Maïeul

    Mars 2021

    4 ans plus tard je relis cela. Et donc : afficher_si ne fonctionne qu’avec #GENERER_SAISIES :)

  • 

    paidge

    Septembre 2021

    J’aurais bien aimé un exemple car je n’arrive pas non plus à utiliser afficher_si avec la balise #SAISIE

  • 

    Maïeul

    Septembre 2021

    Bah justement . afficher si ne PEUT PAS fonctionn avec juste #SAISIE. C’est tout :)

  • 

    paidge

    Septembre 2021

    Message supprimé

  • 

    paidge

    Septembre 2021

    Merci ça j’avais compris ;) Je parlais d’un exemple avec #GENERER_SAISIES. Finalement je pense avoir compris grâce à cet article.

  • 

    Maïeul

    Septembre 2021

    bah c’est pas ce que tu mettais :-)

    tu a reverifié l’article de base sur saisies, réécrit recemment, qui explique comment déclarer un tableau de saisies ? c’est vraiment cela qu’il faut suivre.
    https://contrib.spip.net/Saisies

  • 

    JLuc

    Septembre 2021

    Hop et ça donne : https://git.spip.net/spip-contrib-extensions/tarteaucitron/commit/01ec2dae6e661e1d2ffd5bb7ae9ccd77ffcd5152 [EDIT : lien invalide]

  • 

    Maïeul

    Septembre 2021

    Si c’est pour un formulaire de config, tu peux même simplifier encore en mettant le .html vide, et saisies s’occupe de tout :)

  • 

    RastaPopoulos

    Septembre 2021

    Pourquoi spécialement pour un de config ? Pour n’importe quel form

  • 

    Maïeul

    Septembre 2021

    heu oui tu a raison... c’est juste que j’ai tellement l’habitude de ne faire que du formidable ou de la config avec saisies... que j’ai oublié la propre doc que j’avais écrit...

  Répondre à ce message

• 2

  

  Naema

  Janvier 2019

  Une question qui est probablement souvent posée (et dont je n’ai pas trouvé la réponse -je précise que je l’ai posée aussi sur le forum d’entraide en délayant un peu, et suis un peu perdue sur le fait) : comment élargir la liste des statuts d’auteurs disponibles (par défaut listés au choix parmi : admin/rédacteurs/visiteurs) pour faire apparaître de nouveaux statuts qu’on a au préalable créés (via mes_options et mes_fonctions) ? Je pose la question ici même si mon usage est pour un plugin perso créé avec ajout de ChampsExtras (qui dispose d’un paramétrage : « statuts d’auteurs » pré-sélectionnés pour restreindre la liste d’affichage des auteurs aux statuts prédéfinis — ChampsExtra s’appuie sur Saisie, il me semble). J’ai cru comprendre en lisant le code du fichier des mots-clés (fichier : mots\inc\mots.php, ligne 94-98) qu’il y a apparemment une difficulté à gérer les statuts des objets. Est-ce qu’il y a eu une avancée ou une solution sur ce point ? Ou bien, à défaut, pourrait-on afficher, dans le cas d’un objet qui est lié à un autre, (par ex. les auteurs liés à des mots-clés, ou autre objet créé) l’encart des auteurs avec leurs onglets de statuts, comme la façon dont ils s’affichent dans l’objet natif « Auteurs » (ex. en sélectionnant « afficher les auteurs » cela crée un affichage avec trois onglets en haut de tableau, administrateurs/rédacteurs/à la poubelle et en sélectionnant « afficher les visiteurs » cela crée un affichage avec un onglet visiteurs) ? La solution alternative est bien sûr d’utiliser le plugin « groupes d’auteurs » (ciag) et de sélectionner les groupes, mais les nouveaux statuts ne sont toujours pas pris en compte dans le formulaire de ChampsExtras, donc au pire il faut tout mettre dans « visiteurs » et puis faire un deuxième tri via « affichage sélectif » avec le groupe choisi. Ce qui est un peu dommage en soi, du point de vue informatique ( 2 critères de sélection au lieu d’un seul) et moins pratique si on a vraiment besoin de gérer des statuts différents affichés nativement dans spip sans avoir à passer par un plugin de groupe. Merci pour l’aide éventuelle et j’espère avoir été claire dans la question, c’est difficile d’exprimer ce que l’on veut quand on n’est pas informaticien ni web-developpeur (malgré bac+7 !)

  • 

    franzzz

    Novembre 2019

    Bonjour,
    C’est une constante dans SPIP, de n’avoir que quatre profils généraux. Ce n’est pas comme dans Drupal où le nombre de profils et les autorisations apportées sont (presque) illimitées.
    On peut trouver néanmoins de petites choses qui peuvent aider. Par exemple, vous pouvez définir à l’aide de champs extras différents « droits » que vous implémentez dans de nouveaux champs, et que vous utilisez ensuite dans vos boucles d’auteurs. Bien sur, vous n’avez pas créé des groupes de profils différenciés, et uniquement dans la partie publique du site, mais c’est déjà ça. En utilisant conjointement le plugin accès restreint, vous pouvez arriver à réaliser des merveilles.
    Mon conseil : comme il s’agit d’une différenciation des autorisations dans l’espace publique uniquement, n’ajoutez ces champs qu’aux visiteurs, cela fait un problème en moins pour l’accès à la partie privée.
    Et l’autre option, bien sûr : utiliser Drupal (mais son apprentissage risque d’être dur : drush, twig, composer ...

  • 

    RastaPopoulos

    Juillet 2020

    Je n’ai pas compris à quel endroit tu veux voir afficher les statuts supplémentaires. Il n’y a pas de saisie « statut d’auteurs », donc je ne crois pas que ça ait un rapport avec ce plugin et qu’il faudrait y répondre ici.

    Tu devrais plutôt poser la question sur le forum de Champs Extras à priori, si c’est lui qui construit un select avec uniquement en dur les statuts connus, au lieu de prendre la liste déclaré dans l’objet auteur par l’API.

  Répondre à ce message

• 3

  

  franzzz

  Novembre 2019

  Bonjour,
  Existe-t-il une possibilité d’exclusion de son propre login du champ auteurs ?
  Merci.

  • 

    franzzz

    Novembre 2019

    En répondant à mon propre commentaire, je dirais qu’il faut surement ajouter un id_auteur != #ENVid_auteur dans le fichiers saisies.
    Si j’ajoute dans les options de mon ficher php de formulaire une ligne ’id_auteur’ => $id_auteur (passé en argument pour le formulaire depuis charger, l’id de l’utilisateur est passé (il est bien dans [<pre>(#ENV**|unserialize|print_r{1})</pre>].
    Ma question devient donc :
    Comment faire pour y accéder ? J’ai tenté une syntaxe du style

    #SET{demandeur,#GET{#ENV{_saisies}}}
    #SET{demandeur,#GET{demandeur}|{table_valeur{saisies}}}
    #SET{demandeur,#GET{demandeur}|{table_valeur{0}}}
    #SET{demandeur,#GET{demandeur}|{table_valeur{id_auteur}}}

    qui n’apporte rien, étant entendu que la première valeur du tableau correspond bien à l’id_de l’utilisateur.
    Quelqu’un pour me corriger ?

  • 

    RastaPopoulos

    Novembre 2019

    Bé si t’as passé id_auteur c’est #ENV{id_auteur} quoi, ya pas de feinte. :)

  • 

    franzzz

    Novembre 2019

    Avais testé évidemment ! Mais tu m’as donné la bonne idée : il fallait que je déclarer l’id_auteur DANS le tableau de déclaration POUR la liste d’auteurs (jusqu’à présent, c’était ailleurs), et là ça marche. Merci.

  Répondre à ce message

• 2

  

  paidge

  Novembre 2019

  Bonjour,
  Je suis en train d’apprendre à développer des plugins pour SPIP et j’aimerais faire un formulaire de paramétrage pour un plugin. Avec le plugin SAISIES, je voudrais mettre un sélecteur d’article OBLIGATOIRE mais je n’ai pas l’impression que ce paramètre soit pris en compte.

  [(#SAISIE{selecteur_article, bloc1,
      label=<:theme_x:cfg_premier_bloc:>,
      explication=<:theme_x:cfg_bloc_explication:>,
      obligatoire=oui})]

  • 

    Maïeul

    Novembre 2019

    Le code HTML que vous citez va permettre à ce que la saisie soit affichées comme obligatoire par le site public. En revanche, elle ne permettra pas la vérification du caractère obligatoire par PHP.

    Pour un formulaire de configuration, le plus simple est encore de déclarer vos saisies uniquement en PHP : cela permettra de produire automatiquement le HTML + la vérification.

    C’est expliqué ici.

    https://contrib.spip.net/Saisies#Declarer-un-formulaire-CVT-complet-en-PHP

  • 

    paidge

    Novembre 2019

    OK merci. J’avais vu cet article en effet mais je pensais que le paramètre « obligatoire » de la balise #SAISIE faisait le job vu que ça marchait pour les autres types de champs. Mais finalement je comprends que ça ne faisait qu’ajouter required sur les champs et que c’est le navigateur qui indiquait l’obligation de renseigner le champ.

  Répondre à ce message

• 

  Peetdu

  Février 2019

  Je viens de relever une anomalie avec la saisie Selection.
  Dans le cas d’un objet éditorial fait avec la Fabrique, cette saisie ne prend pas en compte le paramètre defaut.

  [(#SAISIE{selection, test, label=Test, datas=[(#ARRAY{bla, Bla, bli,Bli})], defaut=bli})]

  A la création d’un nouvel objet, la fonction formulaires_editer_objet_charger() va renvoyer $valeurs['test'] = "".
  Du coup #ENV{test} ne sera pas nulle et la ligne https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/saisies/trunk/saisies/selection.html#L40 va shunter la valeur par defaut.

  J’aurais bien proposé une solution, mais n’étant pas à l’aise avec cette syntaxe « à rallonge », je préfère vous passer la main.

  A vous les studios :)

  Répondre à ce message

• 4

  

  Keny972

  Juillet 2017

  Bonjour,

  Petite question : comment, si c’est possible, ajouter à un champ SAISIES une span message_erreur ? Pas le message erreur_obligatoire, mais celui qui est récupérer de la fonction vérifier du formulaire CVT.

  merci d’avance

  • 

    RastaPopoulos

    Juillet 2017

    Pas compris la question, dans 100% des saisies il y a une balise de message d’erreur quand il y a une erreur pour ce name de champ dans l’environnement du CVT.

  • 

    Keny972

    Juillet 2017

    La seule option erreur indiquée ici, c’est erreur_obligatoire qui permet de « personnaliser le message d’erreur affiché pour indiquer l’obligation (sinon laisser vide). »

    Dans un formulaire standard si je veux indiquer une erreur, j’ai quelque chose de ce type :

    <div class="editer_synth">
    		<label for="synth"><:incident:label_synth:></label>
    		[<span class="erreur_message">(#ENV**{erreurs}|table_valeur{synth})</span>]
    		<input type="text" name="synth" id="synth" />
    </div>

    mais dans mon cas j’utilise le plugin SAISIES :

     #SAISIE{input,synth}

    Que dois-je ajouter à cette balise pour une erreur standard plutot qu’une erreur_obligatoire ?

  • 

    RastaPopoulos

    Juillet 2017

    Mais y a rien à ajouter, c’est à toi de mettre des erreurs dans ton tableau habituel des erreurs de CVT dans la fonction verifier(), avec le bon nom du champ.

  • 

    Keny972

    Juillet 2017

    Dans ce cas je dois avoir une erreur autre part, parce que le code dans ma fonction vérifier() existe pour gérer les erreurs.
    Merci tout de même.

  Répondre à ce message

• 

  chankalan

  Mai 2017

  hello,
  il est possible de mettre plusieurs conditions à un afficher_si, exemple :

  ’afficher_si’ => ’@parametre1@==« on » && @parametre2@==« on »’

  Est-ce qu’on pourrait l’ajouter à la documentation ?

  Répondre à ce message

• 2

  

  Thom

  Mars 2016

  Bonjour,

  Je crée un nouveau plugin à l’aide du plugin fabrique. Celui-ci crée des formulaires qui sont réalisé avec le plugin saisie. Dans mon plugin, j’ai créé 2 nouveaux objets éditoriaux. Je souhaite que l’un des 2 soit éventuellement relié à l’autre.

  Du coup, j’aimerais pouvoir faire un champ de sélection comme selecteur_article ou selecteur_rubrique, mais dont qui selection l’id de l’un de mes 2 objets. Est ce possible avec « saisie » ? et comment ?

  Merci beaucoup,

  Thom

  • 

    Thom

    Mars 2016

    OK, j’ai trouvé !!

    Le plugin Fabrique rajoute automatique un type de saisie pour chaque nouvel objet éditorial !

  • 

    RastaPopoulos

    Mars 2016

    Oui pour les listes simples c’est parfait. Après les sélecteurs « navigateur » c’est plus pour les objets complexes avec arborescence, etc. :)

  Répondre à ce message

• 1

  

  mj

  Mars 2015

  Bonjour

  j’ai un petit souci concernant le champ « date » et le Datepicker, lors de la création de champs « au vol » en jquery.

  Si je .clone() un champ date existant, même en initialisant le Datepicker, la saisie avec le calendrier ne fonctionne pas et c’est très ennuyeux.

  J’ai bien débuggué, fait .removeClass(« datePicker »), mais rien à faire.

  Une piste ?

  Merci

  • 

    RastaPopoulos

    Avril 2015

    Bon, une réponse en retard mais qui n’en est pas une, vu que je n’ai pas grand chose à y dire… :)

    Je ne sais pas si ça à un rapport spécifique à Saisies puisque Saisies ne fait rien (ça génère juste le HTML, incluant des appels à JS parfois). Ça a plus l’air d’être un problème JS, d’autant plus que le sélecteur de date n’est même pas non plus dans Saisies, mais est une inclusion d’une librairie fournie par le noyau de SPIP. Théoriquement ça doit pouvoir être appelé indépendamment donc…

  Répondre à ce message

• 3

  

  bruno31

  Octobre 2012

  Bonjour

  De la même manière qu’ils existent auteur, destinataire, selecteur_article, selecteur_rubrique, existe t’il un selecteur_document ?

  • 

    RastaPopoulos

    Octobre 2012

    Oui ya ça dans le dossier : http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/selecteur_document.html

    Les gens qui ont ajouté des saisies n’ont pas forcément ajouté le YAML qui les décrit.

  • 

    bruno31

    Octobre 2012

    Effectivement, le fichier selecteur_document.html est bien présent de base dans le plugin SAISIES.
    Mais il manque selecteur_document.yaml.
    Je l’ai fait en partant d’un autre yaml :

    titre: '<:saisies:saisie_selecteur_document_titre:>'
    description: '<:saisies:saisie_selecteur_document:>'
    icone: 'images/saisies_selecteur_article.png'
    options:
      -
        saisie: 'fieldset'
        options:
          nom: 'description'
          label: '<:saisies:option_groupe_description:>'
        saisies:
          -
            saisie: 'input'
            options:
              nom: 'label'
              label: '<:saisies:option_label_label:>'
              explication: '<:saisies:option_label_explication:>'
              size: 50
          -
            saisie: 'input'
            options:
              nom: 'explication'
              label: '<:saisies:option_explication_label:>'
              explication: '<:saisies:option_explication_explication:>'
              size: 50
      -
        saisie: 'fieldset'
        options:
          nom: 'affichage'
          label: '<:saisies:option_groupe_affichage:>'
        saisies:
          -
            saisie: 'input'
            options:
              nom: 'attention'
              label: '<:saisies:option_attention_label:>'
              explication: '<:saisies:option_attention_explication:>'
              size: 50
          -
            saisie: 'input'
            options:
              nom: 'info_obligatoire'
              label: '<:saisies:option_info_obligatoire_label:>'
              explication: '<:saisies:option_info_obligatoire_explication:>'
      -
        saisie: 'fieldset'
        options:
          nom: 'obligatoire'
          label: '<:saisies:option_groupe_validation:>'
        saisies:
          -
            saisie: 'oui_non'
            options:
              nom: 'obligatoire'
              label: '<:saisies:option_obligatoire_label:>'
    defaut:
      options:
        label: '<:saisies:saisie_selecteur_document_titre:>'
        # champs extras (definition du champ sql)
        sql: "text DEFAULT '' NOT NULL"

    Ca marche à peu près correctement sauf si j’utilise le sélecteur de document dans le YAML d’un modèle de saisie perso (lui-même appelé dans un formulaire FORMIDABLE). Le sélecteur de document est bien affiché dans le formulaire, la boite modal de sélection est bien appelée, mais quand je sélectionne l’image je ne reviens pas sur mon formulaire.

    Par contre, ça marche quand on insère un selecteur_document dans un formulaire FORMIDABLE.

  • 

    bruno31

    Janvier 2015

    selecteur_document.yaml n’était toujours pas sur la Zone.
    Je viens de l’ajouter.

  Répondre à ce message

• 11

  

  DavidM

  Mai 2014

  Bonjour,
  Je cherche à faire des champs conditionnels avec Formidable, mais je n’y arrive pas.

  Pour un champ après celui de case unique (qui doit donc déclencher la suite, qui s’appelle @case_1@), je met @case_1@==« on »,
  dans :
  Affichage conditionnel lors du remplissage
  Contrairement à la précédente option, celle-ci ne conditionne l’affichage que lors du remplissage du formulaire, pas lors de l’affichage des résultats. Sa syntaxe est la même.

  Seulement, même si je coche la case unique, le champ conditionnel lié ne s’affiche pas.
  j’ai essayé aussi avec @case_1@==« 1 »

  Cette fonction est-elle impossible, ou j’ai mis les mauvais codes ?
  Quelle sont les valeurs pour les cases uniques ?

  Merci pour toute aide utile

  • 

    DavidM

    Mai 2014

    Précision : avec @case_1@==« oui » ça ne marche pas non plus

  • 

    gomech

    Décembre 2014

    Bonjour David,

    J’ai réussi a saisir une conditionnelle est-ce bon pour toi ? De mon coté mon problème et que je ne parvient pas à intégrer deux conditionnelles à savoir :
    si @selection_3@==« un » et @selction_3@==« deux » alors ça s’affiche. Est-ce que vous pouvez me débloquer ?
    Merci d’avance

  • 

    RastaPopoulos

    Décembre 2014

    Avec un « and » entre les deux ?

  • 

    gomech

    Décembre 2014

    Non ça ne fonctionne pas. Si je rajoute une conditionnelle, ça m’annule tous les paramétrage et tous les champs qui devaient apparaitre en conditionnelle s’affichent.
    Voici ce que j’ai mis : @selection_4@==« Un » and @selection_4@==« Deux »

  • 

    RastaPopoulos

    Décembre 2014

    et en replaçant « and » par « && » ?

  • 

    gomech

    Décembre 2014

    Non ca ne fonctionne pas . Voila ce que j’ai mis : @selection_4@==« Un »&&@selection_4@==« Deux »
    Est-ce qu’il faut des espaces entre ?
    La j’avoue je bloque complétement si tu as d’autres idées, je suis preneuse.

    Merci ;-)

  • 

    RastaPopoulos

    Décembre 2014

    pas entre, autour. Mais si ni « and » ni « && » ne fonctionne, là je ne sais pas. Il me semblait qu’on pouvait faire des opérations complexes avec « and » et « or » aussi, pourtant. Peut-être avec des parenthèses autour de l’ensemble… Pour l’instant je n’ai pas le temps de lire le code qui gère ça, il faudra voir avec Joseph sinon, qui est l’auteur du code qui gère cette fonctionnalité.

  • 

    gomech

    Décembre 2014

    tu n’aurais pas une autre idée à me suggérer ?

  • 

    gomech

    Décembre 2014

    Comme ceci :
    &@selection_4@==« Un » @selection_4@==« Deux »&
    cela ne fonctionne pas
    Merci rasta popoulos pour ton aide.
    Comment joindre Joseph car la vraiment pas d’idée et je trouve rien à ce sujet sur le net

  • 

    RastaPopoulos

    Décembre 2014

    Euuh, ça veut rien dire, le « && » remplace le « and », entre les deux, ça veut dire pareil en programmation « && » et « and ».

    Sinon, peut-être en posant la question sur la liste spip-zone, dédiée aux plugins.

  • 

    gomech

    Décembre 2014

    Désolé Rastapopoulos mais je suis une quiche en programmation...lol
    J’ai juste récupéré un site sous spip et je tente désespérément de mettre en place une formulaire...
    Donc si je te suis bien tu me dis de mettre ceci :
    @selection_4@==« Un » and @selection_4@==« Deux » ?

    Merci pour ton aide

  Répondre à ce message

• 2

  

  robomatix

  Mars 2014

  Bonjour,

  Est ce SAISIE gère les champs pour télécharger des fichiers ?

  Je n’ai rien trouver la dessus et ça ne semble pas être indiqué ici comme le faisant, mais j’aimerais en être sur !

  Merci d’avance de votre réponse.

  • 

    RastaPopoulos

    Mars 2014

    Pour l’instant non. C’est surtout à CVT en premier lieu de savoir gérer les fichiers en gardant temporairement en mémoire ce qui a été téléchargé si jamais un champ est en erreur dans verifier(), pour ne pas devoir le retélécharger à chaque fois. J’eus aimé que ce problème soit résolu génériquement en amont (dans CVT donc), ce qui permettrait alors de l’intégrer dans Saisies sans effort.

  • 

    robomatix

    Mars 2014

    Merci de cette précision rapide.

    Bonne journée !

  Répondre à ce message

• 2

  

  gilcot

  Juillet 2011

  Je ne sais pas si je suis au bon endroit (en fait je pensais trouver une réponse dans les références) mais voilà : est-ce la bonne écriture (j’ai des erreurs d’include et des erreurs liées aux fonctions de tableaux) sinon comment faire ?

  [(#SAISIE{fieldset, presentation. label=<:a_mon_sujet:>,
      saisies=#ARRAY {
          1, #ARRAY {
              saisie, selection,
              nom, sexe,
              label, 'je suis',
              datas, #ARRAY{h, homme, f, femme,},
              },
          }
  })]

  Le fieldset s’affiche (bien entendu vide) sans l’option saisies ; et le tableau de tableaux (inspiré des exemples en PHP) doit représenter (qui fonctionne aussi)

  [(#SAISIE{selection, sexe, label='je_suis', datas=#ARRAY{h,homme,f,femme,} })]

  Merci d’avance de vos lumières (en plus je suis sur que ce doit être tout simple)

  • 

    RastaPopoulos

    Juillet 2011

    La balise #SAISIE est un peu à part, elle a été faite avant le développement de la vraie interface de programmation autour des saisies. On ne peut pas mettre de fieldset avec et on ne peut pas l’utiliser pareil que les descriptions en tableau PHP.

    En PHP, l’attribut « saisies » n’est PAS dans les « options », or la balise #SAISIE ne prend que les options en paramètre.

  • 

    gilcot

    Juillet 2011

    C’est bien vrai que l’attribue (liste de) saisies n’est pas dans les options... Maintenant c’est plus clair : si on veut utiliser les fieldset (en dehors de tableau PHP passé à l’API) il faut le faire à la main comme je viens de le voir ailleurs
    Un grand MERCI pour la réponse (sans quoi on aurait continuer à se cogner la tête ici et à retourner la balise inutilement dans tous les sens)

  Répondre à ce message

• 2

  

  bruno31

  Juin 2013

  Bonjour

  Dans un PHP, Je construis une saisie de type sélection :

  array(
  	'saisie' => 'selection',
  	'options' => array(
  		'nom'         => 'calc_essence',
  		'label'       => _T('calcbois:calc_entraxe_calc_essence'),
  		'datas'       => array(1=>"TOTO", 1=>"TITI", 2=>"TATA"),
  		'obligatoire' => 'oui'
  	)

  Comme vous pouvez le voir, la valeur retournée par le select peut être présente plusieurs fois.
  Dans l’exemple, si je sélectionne TOTO ou TITI, je veux que cela me retourne 1 dans les deux cas. C’est permis en HTML.

  Problème : les index d’un tableau PHP sont uniques. Dans l’exemple, seul TITI sera affiché.

  Comment faire pour avoir plusieurs fois le même index dans le select ?

  MERCI

  • 

    RastaPopoulos

    Juin 2013

    Les valeurs étant basées sur les clés d’un tableau PHP, cela n’est effectivement pas permis par l’API pour l’instant. C’est un peu con, ouais, ça partait d’une manière simple de faire (c’était déjà comme ça avant l’API PHP en fait, quand il n’y avait que #SAISIE).

    De manière rapide, à court terme, je ne vois pas de solution simple. Mis à part traiter en PHP dans le traiter() du CVT pour uniformiser les valeurs qui doivent être regroupées.

    Je crois que ça restera comme ça car le principe des saisies c’est de marcher dans les deux sens : quand on sélectionne une valeur, ça POST ça au formulaire, mais inversement, quand le formulaire pré-remplis un des champs avec une valeur : ça doit pouvoir sélectionner un des choix !

    Or là si le charger() dit que par défaut « calc_essence » => 1, la saisie ne peut pas savoir quelle est la valeur où mettre « selected » dans le HTML.

  • 

    bruno31

    Juin 2013

    Merci

    Je vais effectivement regrouper les valeurs avec un | puis faire un explode dans traiter.

  Répondre à ce message

• 3

  

  tcharlss

  Février 2013

  Bonjour,

  Je reporte un petit souci que je viens de rencontrer avec la saisie case : l’option pour définir une valeur par défaut n’est pas prise en compte.
  Dans le squelette de la saisie, on teste la présence d’une valeur enregistrée ou forcée avec le filtre |is_null pour savoir s’il faut utiliser la valeur par défaut, c’est là que ça coince je pense.

  #SET{valeur,#ENV{valeur_forcee,#ENV{valeur}}|is_null|?{#ENV{defaut},#ENV{valeur_forcee,#ENV{valeur}}}}

  En remplaçant par ceci, tout semble rentrer dans l’ordre :

  #SET{valeur,#ENV{valeur_forcee,#ENV{valeur,#ENV{defaut}}}}

  Je n’ai pas testé cette modif dans toutes les situations par contre.
  Voilà la saisie sur laquelle j’ai testé :

  [(#SAISIE{case, ma_saisie,
   	valeur_oui: 1,
  	defaut: 1})]

  En passant, je ne sais pas si c’est envisageable mais ce serait tip-tip de pouvoir également utiliser l’option valeur_non=xxx

  Voilà voilà

  • 

    tcharlss

    Février 2013

    Ah j’ai oublié : Saisies v.1.30.0 sur SPIP 3.05

  • 

    RastaPopoulos

    Février 2013

    Ça ne peut pas marcher non plus, car justement la valeur « non cochée » par défaut c’est que la chaîne vide «  ». Du coup, avec ce test, quand la case a été explicitement non-cochée, et que la valeur vaut «  », ça va utiliser la valeur par défaut à la place. D’où le is_null.

    Le problème du is_null c’est qu’avec CVT il est apparemment impossible d’avoir NULL comme valeur du tableau de déclaration des champs de la fonction charger(). Et du coup on a toujours la chaîne vide au minimum à la place. Et du coup impossible d’avoir la valeur par défaut la première fois.

    Ceci vaut pour les deux saisies « oui_non » et « case ». Et peut éventuellement être résolu quand on défini explicitement d’autres valeurs pour oui et pour non (faut juste améliorer les tests mais c’est possible). Mais pour le cas par défaut qui est : plein=oui, vide=non, ça ne marchera pas tant qu’on ne pourra pas avoir du NULL dans une variable. Ce choix par défaut (plein/vide) est dû au fait qu’ensuite il est plus facile d’utiliser un test #ENV{ma_valeur}|oui.

  • 

    tcharlss

    Février 2013

    Merci pour les explications, du coup je viens de refaire quelques tests avec la modification pour en avoir le coeur net, ça m’a pourtant l’air de marcher.

    • Avec la saisie la plus simple possible : #SAISIE{case, test, defaut='on'}, dans un nouveau formulaire la case est bien cochée au début, et si je la décoche, un echo(_request('test')) à la fin de la fonction traiter me renvoie bien une valeur NULL au lieu de la valeur ’on’ par défaut.

    • Avec #SAISIE{case, test, valeur_oui='toto', defaut='toto'}, même procédure et même résultat.

    Alors je ne serais bien en peine d’expliquer pourquoi, mais en tout cas empiriquement, ça m’a l’air bon. En tout cas, c’est le comportement attendu : avoir la possibilité qu’une case soit cochée par défaut lors de la première édition d’un formulaire.

  Répondre à ce message

• 7

  

  Sylvain

  Février 2013

  Bonjour,

  pourquoi ne veut-il pas de l’option class ?

  [(#SAISIE{input, body_bg,
  	label=<:plugin:cfg_body_bg:>,
  	explication=<:plugin:cfg_body_bg_explication:>},
  	class=colorpicker
  	)]

  il répond Filtre , class=colorpicker non défini

  merci d’avance

  • 

    RastaPopoulos

    Février 2013

    Regarde l’emplacement de ton accolade fermante. :)

  • 

    Sylvain

    Février 2013

    je viens de m’en apercevoir,

    merci :-)

  • 

    Sylvain

    Février 2013

    Je n’est plus le message d’erreur, par contre, ça ne rajoute pas ma « class » au « input » ???
    (actuellement sur les dernières versions de SPIP et plugins)

  • 

    RastaPopoulos

    Février 2013

    © Chez-moi-ça-marche.

    Ya pas de code compliqué en plus là, c’est juste un class=#ENV{class} dans le squelette de ce champ, donc ya pas de raison que ça n’y soit pas...

    var_mode=debug pour voir les paramètres passés au morceau de squelette

  • 

    Sylvain

    Février 2013

    C’est bien ce que je pensais : rien de compliqué, à priori

    en fait, c’est probablement une incompréhension de ma part, mais ceci ne fonctionne pas

    [(#SAISIE{input, couleur,
    	label=<:couleur:>,
    	class=colorpicker
    	})]

    cette syntaxe oui

    [(#SAISIE{input, couleur}
    	{label=<:couleur:>}
    	{class=colorpicker}
    	)]

    c’est vrai que suivant ce qui est passé, il faut adopter une syntaxe ou une autre

    merci pour ta patience ;-)

  • 

    RastaPopoulos

    Février 2013

    Chez moi ça marche très bien avec la syntaxe récente et préconisée désormais, sans accolade partout. Sinon tu sais qu’il y a une saisie « couleur » dans le plugin ? Qui ajoute la classe « palette », ce qui fait que si tu as le plugin Palette, ça t’ajoute le colopicker.

  • 

    Sylvain

    Février 2013

    J’ai trouvé la source de mon erreur, la syntaxe ci-dessous ne marche pas

    [(#SAISIE{input, couleurs_entete_bg,
    	label=<:mon_plugin:couleurs_entete_bg:>,
    	class=palette
    	})]

    car l’accolade fermante n’était pas collée à la dernière option : class=palette}
    à la rigueur, si l’on met une virgule et laisse l’accolade plus bas ça marche aussi

    et pour « Palette » ; oui !
    je l’ai trouvée entre temps, et donc déjà intégrée
    (autant ne pas marcher sur les pieds des copains ;-) )

    merci

  Répondre à ce message

• 2

  

  Teenoo

  Octobre 2012

  Bonjour,

  est-ce qu’à la base « Sélecteur d’article » peut permettre l’ajout de plusieurs articles ? En effet, je teste mais je ne peux insérer qu’un seul article or j’aimerais en sélectionner plusieurs. Comment puis-je faire ?

  Merci pour votre réponse :)

  • 

    RastaPopoulos

    Octobre 2012

    multiple=oui

  • 

    Teenoo

    Octobre 2012

    Effectivement avec la mise à jour ça va mieux ^^ Merci

  Répondre à ce message

• 2

  

  gilcot

  Octobre 2012

  Bonjour.

  J’ai un souci avec les listes déroulantes, mais je crois que je postais au mauvais endroit.
  Voici la section de formulaire incriminée : [(#SAISIE{selection, type, label=<:coordonnees:label_type_adresse:>, datas=#ARRAY{work,<:coordonnees:type_adr_work:>, home,<:coordonnees:type_adr_home:>, pref,<:coordonnees:type_adr_pref:>, postal,<:coordonnees:type_adr_postal:>, dom,<:coordonnees:type_adr_dom:>, intl,<:coordonnees:type_adr_intl:>, parcel,<:coordonnees:type_adr_parcel:> } })]
  Voici le problème : à l’édition, toutes les saisies récupèrent bien le contexte ...sauf cette sélection ! (il ne met pas la valeur courante en « selected » dans le HTML généré). Du coup j’ai quand même rajouté un « defaut » : [(#SAISIE{selection, type, label=<:coordonnees:label_type_adresse:>, defaut=#ENV{type}, datas=#ARRAY{work,<:coordonnees:type_adr_work:>, home,<:coordonnees:type_adr_home:>, pref,<:coordonnees:type_adr_pref:>, postal,<:coordonnees:type_adr_postal:>, dom,<:coordonnees:type_adr_dom:>, intl,<:coordonnees:type_adr_intl:>, parcel,<:coordonnees:type_adr_parcel:> } })] mais ça ne change rien et je ne sais plus trop quoi faire...

  Merci.

  • 

    RastaPopoulos

    Octobre 2012

    Et il y a bien quelque chose en #ENV{type} ?

  • 

    gilcot

    Octobre 2012

    Ah... Il devrait (les valeurs existent dans la table et sont passées au formulaires) ; mais effectivement je n’ai rien (et c’est le seul paramètre qui semble poser souci) :-S Visiblement le souci ne vient pas de #SAISIE mais est en amont..?

    Merci beaucoup.

  Répondre à ce message

• 2

  

  YannX

  Mai 2012

  Une info récupérée sur IRC, et transcrite pour mémorisation...

  Vous pouvez vouloir utiliser un tableau comme objet saisi dans un CVT (pour utilisation dans une boucle, pour avoir plusieurs valeurs...).

  En .php on utilise souvent directement :
  <input  name="mot[]" ...

  En utilisant le plugin SAISIES, on tente de générer :
  #SAISIE{input,mot[]....} qui ne fonctionne pas...
  utilisez les entites HTML avec [ \ à la place

  • 

    gilcot

    Octobre 2012

    En général quand on veut utiliser un tableau et passer/récupérer plusieurs valeurs, au lieu d’une saisie « input » pourquoi ne pas utiliser une saisie « checkbox » ou « selection » ? ;-)

  • 

    RastaPopoulos

    Octobre 2012

    @gilcot ça c’est seulement quand les valeurs sont pré-définies. Un input on met ce qu’on veut dedans.

  Répondre à ce message

• 2

  

  Juillet 2012

  Salut,

  Dans le sélecteur d’articles, est-il possible de ranger les titres de façon ante-chronologique ?

  [(#SAISIEselecteur_article,ids_article,
  label=<:lettres_objets:label_choisir_articles :>,
  defaut=#ENVids_article,
  multiple=oui)]

  Merci de vos réponses.

  • 

    Artlogic

    Juillet 2012

    Les articles et non les titres pardon, par ordre ante-chronologique. C’est pour sélectionner des articles d’actualités. Hors pour l’instant nous avons toujours les articles les plus récents en fin fond de pagination.

  • 

    gilcot

    Octobre 2012

    Salut.

    Je me demande s’il n’est pas possible de « surcharger » le code du sélecteur ;-)

  Répondre à ce message

• 4

  

  ttseo

  Avril 2012

  Bonjour,
  avec le mode de saisie date, le format renvoyé est du type 12/04/2012.
  Lorsque je définie dans ma table sql le format date, il impose 2012-04-12.
  Du coup, il y a une erreur au moment de l’enregistrement.
  Y-a-t-il un moyen pour reccupérer ce bon format, ou modifier le format avant l’enregistrement dans la base ?
  merci

  • 

    RastaPopoulos

    Avril 2012

    Oui, depuis peu la vérification de date sait normaliser la valeur final avant traitement. Pour ça il faut mettre à jour Vérifier et Saisies, et utiliser la vérification de date avec son option de normalisation.

    Cf. : http://zone.spip.org/trac/spip-zone/changeset/57473/_plugins_/verifier/verifier/date.php

  • 

    Avril 2012

    Merci ... j’ai eu récemment d’autres indications de votre part sur un autre forum !
    Si j’ai bien compris, je dois utiliser vérifier($valeur,’date’,array(’normaliser’ => ’date’) ;

    mais avec le plugin saisies, j’ai dans mon fichier de traitement php du formulaire quelquechose du type :

    function formulaires_editer_programme_colle_identifier_dist($id_programme_colle=’new’,$retour=’’, $config_fonc=’’, $row=array(), $hidden=’’)
    return serialize(array(intval($id_programme_colle))) ;
    

    function formulaires_editer_programme_colle_verifier_dist($id_programme_colle=’new’, $retour=’’, $config_fonc=’’, $row=array(), $hidden=’’)

    return formulaires_editer_objet_verifier(’programme_colle’, $id_programme_colle) ;
    

    function formulaires_editer_programme_colle_traiter_dist($id_programme_colle=’new’,$retour=’’,$config_fonc=’’, $row=array(), $hidden=’’)
    return formulaires_editer_objet_traiter(’programme_colle’,$id_programme_colle,$retour,$config_fonc,$row,$hidden) ;
    

    où alors insérer la vérification ? (je me suis inspirer pour réaliser le plugin de l’exemple « chats »)
    d’avance merci

  • 

    RastaPopoulos

    Avril 2012

    La vérification se fait dans la fonction... tin tin tin... verifier() ! :)

    $truc = _request('truc'); pour récupérer ce qui a été posté, suivant le nom du champ, et ensuite tu en fais ce que tu veux, donc le passer dans la fonction de l’autre plugin Vérifier (cf sa doc).

    Mais le plus simple, quand on a pas un formulaire horriblement compliqué, ça reste quand même de déclarer ses saisies en PHP. En effet ce plugin permet d’étendre CVT avec un S : function formulaire_montruc_saisies_dist($param1, $param2, etc)

    Cette fonction doit retourner un tableau de saisies valides, comme décrit dans la documentation (cf l’article de base de la doc de ce plugin).

    Avec cette fonction Saisies sait même faire les 2/3 du boulot : ça déclare les champs ET ça vérifie (pour peu qu’on ait décrit les vérifications à faire comme l’explique la doc de Vérifier).

    Ok ok un exemple complet serait bienvenu, je sais...

  • 

    ttseo

    Avril 2012

    OK, merci.
    Une question qui n’a pas de lien direct, mais je ne vois pas où la poser :
    comment faire migrer une base de spip2 vers spip3 ? la démarche habituelle n’a pas fonctionné chez moi...
    merci

  Répondre à ce message

• 6

  

  tcharlss

  Mars 2012

  Bonjour,

  Avec une saisie ’sélection’, je ne parviens pas à faire en sorte que la valeur par défaut soit pré-sélectionnée.
  Voilà mon bout de squelette, je pécise que c’est dans une boucle DATA, ça a peut-être son importance :

  [(#SAISIE*{#VALEUR{type_saisie}, #VALEUR{parametre},
  	datas=#VALEUR*{datas},
  	defaut=#VALEUR*{defaut}
  })]

  Ce qui me rend perplexe, c’est qu’avec le même code ça marche bien pour une saisie radio (la valeur par défaut est bien cochée). Aurais-je loupé quelque chose ?

  • 

    RastaPopoulos

    Mars 2012

    Là comme ça ça ressemble à un bug, mais j’ai pas eu le temps de regarder le code encore. Peut-être qu’il faut que ce soit un tableau ? À voir dans saisies/selection.html.

  • 

    tcharlss

    Mars 2012

    Ah oui, en changeant [(#CLE|=={#GET{valeur}}|oui)selected="selected"] en [(#CLE|=={#ENV{defaut}}|oui)selected="selected"] dans saisies/selection.html, ça marche.
    #GET{valeur} ne renvoie rien, il doit y avoir un souci avec le #SET.

  • 

    RastaPopoulos

    Mars 2012

    As-tu essayé d’afficher le contenu du #GET pour savoir ce qu’il contient au final ? [(#GET{valeur}|var_dump)]

  • 

    tcharlss

    Mars 2012

    Ah oui avec |var_dump, la valeur est bien là : string(4) « fade ».
    Du coup en utilisant match à la place du ==, ça semble marcher :
    [(#CLE|match{#GET{valeur}}|oui)selected="selected"]

  • 

    RastaPopoulos

    Mars 2012

    Ouais mais ça fait faire une regex pour rien alors que c’est juste une comparaison de chaîne toute bête (et en plus si ya « truc » dans « machin truc » ça le trouvera aussi avec ce que tu as mis :) ).

    Il doit y avoir un espace quelque part, un truc dans ce genre. Dans ton tout premier code ça fait quoi si tu fermes la balise #SAISIE juste après le defaut : defaut}})] ?

    Mais c’est bizarre car le dump trouve une chaîne sans espace donc c’est peut-être #CLE (donc ce que tu as mis dans « datas » qui contient des espaces superflues) ? Faudrait dumper #CLE aussi pour comparer.

  • 

    tcharlss

    Mars 2012

    Dans ton tout premier code ça fait quoi si tu fermes la balise #SAISIE juste après le defaut : defaut}})] ?

    Oh pétard, c’était ça ! Hum, j’étais pourtant sûr d’avoir vérifié avec et sans crochets auparavant.
    Désolé pour le bruit !

  Répondre à ce message

• 1

  

  anaïs

  Septembre 2011

  J’essaie de faire un formulaire en utilisant destinataires et type_choix ne me donne pas le résultat escompté. En revanche, multiple=oui produit l’effet attendu (comme mentionné dans l’article sur Saisies).

   :-)

  • 

    RastaPopoulos

    Septembre 2011

    Euh « multiple=oui » n’existe pas du tout dans le code de cette saisie.

    Cf http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/destinataires.html

    C’est « type_choix=plusieurs » qu’il faut.

  Répondre à ce message

• 2

  

  Fred Montessinos

  Avril 2011

  Bonjour,

  Pour mettre à jour une table « categories » qui contient les champs suivants : id_categorie , nom, id_sup, infos, j’utilise une formulaire avec saisie. Pour le champ de la categorie parente, actuellement je fais ça :

  [(#SAISIE{input, id_sup,
  label=<:categories:label_parent:>})]

  Ce n’est pas très pratique puisqu’il faut renseigner l’id de la categorie voulue. J’ai essayé de faire un champ selection, pour pouvoir sélectionner le nom de la categorie parente et récupérer l’id, mais je n’y arrive pas. Ma dernière tentative était

  [(#SAISIE{selection, id_sup}
          {label=<:categories:label_parent:>}
          {option_intro=Sélectionnez une categorie parente}
          {datas=#INFO_NOM{categorie, #ID_SUP}}
  )]

  Mais bien sur ça ne va pas.
  Un coup de pouce serait bienvenue
  merci
  Fred

  • 

    RastaPopoulos

    Avril 2011

    datas doit être un tableau PHP. Donc #ARRAY{cle1, valeur1, cle2, valeur2, etc} dans un squelette SPIP. À construire avec une boucle sur tes catégories avant d’afficher ta saisie selection.

  • 

    Fred Montessinos

    Avril 2011

    Merci beaucoup.
    C’est presque bon, il reste juste un petit problème « option_intro » ne s’affiche plus par défaut, il est en deuxième choix dans la liste.

    Pour info :

    Ma boucle

    #SET{array_categories, #ARRAY}
    <B_crit>		
    <BOUCLE_crit(CATEGORIES)>
            #SET{array_categories,#GET{array_categories} |array_merge{#ARRAY{#NOM,#ID_CATEGORIE}}}       
    </BOUCLE_crit>
    #SET{array_categories, #GET{array_categories}|array_flip}      
    </B_crit>

    et mon champ selection :

    [(#SAISIE{selection, id_sup}
            {label=<:categories:label_parent:>}
            {option_intro=Sélectionnez une categorie parente}
            {datas=#GET{array_categories}}
    		)]		

  Répondre à ce message

• 5

  

  Mojo

  Avril 2011

  Salut la compagnie !

  A quand une Saisie « DATE », idéalement identique à celle implémentée dans Formidable ?
  C’est a dire un input de taille réduite (10 caractères), un picto « calendrier » sur la droite qui ouvre un calendrier, et remplit le champ automatiquement.

  Mojo

  • 

    RastaPopoulos

    Avril 2011

    Euh... Formidable utilise UNIQUEMENT ce plugin Saisies. Donc elle y est. :)

    Mais faut mettre la doc à jour de temps en temps... :(

  • 

    Mojo

    Avril 2011

    Damned, j’ai été eu ^^
    Dans un sens, tant mieux, c’est tellement pratique ce champ date !

  • 

    Mojo

    Avril 2011

    Par contre, est-il actuellement possible de positionner le datepicker sur la date chargée ou entrée, ou en tout cas de l’initialiser à une certaine date ? Par défaut, il part du 1^er janvier 1900 dans tous les cas.

  • 

    RastaPopoulos

    Avril 2011

    Chez-moi-ça-marche. ©

    Si il n’y a rien, ça part d’aujourd’hui. Et s’il y a une date, ça part de celle-ci.

  • 

    Mojo

    Avril 2011

    En effet, j’ai eu ce comportement sur des DATETIME à 0000-00-00 par defaut...
    Ca marche nickel Chrome© ^^

  Répondre à ce message

• 3

  

  Jean-Baptiste Pressac

  Janvier 2011

  Bonjour,
  Concernant l’option datas, je ne comprends pas la mention :

  Vous devez indiquez un choix par ligne sous la forme « cle|Label du choix »

  Du coup, j’avais essayé de renseigner l’option de cette façon :

  datas=
  cle1|valeur1,
  cle2|valeur2,
  cle3|valeur3

  Qui n’avais pas marché. Mais j’ai trouvé dans selection_mutliple.html l’exemple suivant :

  datas=#ARRAY{cle1,valeur1,cle2,valeur2,cle3,valeur3}

  Si l’utilisation d’un tableau est systématique pour la saisie des valeurs de datas, ne vaudrait-il pas mieux le préciser ci-dessus ?

  • 

    RastaPopoulos

    Janvier 2011

    On peut soit mettre un #ARRAY, soit mettre un choix pas ligne, donc dans une chaine de caractères, ce qui n’est pas le cas de l’exemple ci-dessus avec les virgules. La chaine permet de passer ces valeurs depuis le résultat d’un textarea par exemple.

  • 

    Jean-Baptiste Pressac

    Janvier 2011

    Quand vous dites « mettre un choix pas ligne, donc dans une chaine de caractères » cela signife-t-il qu’on peut écrire ? :

    datas="cle1|valeur1
    cle2|valeur2
    cle3|valeur3"

    En fait, je ne comprends pas très bien ce que vous entendez par « un choix par ligne ».

  • 

    RastaPopoulos

    Janvier 2011

    Une ligne comme dans dans toute chaine de caractère quoi. « \n ».

    La fonction qui récupère ça :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/inc/saisies.php#L746

    Mais quand on est dans un squelette, ça n’a pas d’intérêt, il faut utiliser #ARRAY évidemment.

  Répondre à ce message

• 7

  

  stefdn

  Décembre 2010

  bonjour,

  je découvre ce plugin fort utile et j’ai quelques remarques et questions :

  1. il me semble que l’attribut title n’est pas dispo, il serait utile comme option générique non ?
  2. ou, d’une manière plus générale, ne serait-il pas possible d’implémenter une option de saisie attributs qui serait une liste :
     'attributs' => array('attribut' => 'valeur')

  1. je ne trouve pas de références aux boutons (submit, image, reset) ... faut les traiter en dehors des saisies ?
  2. j’essaie d’afficher la saisie explication, sans succès. Une idée ? :

  dans formulaires/testou.php :

  function formulaires_testou_charger_dist() {
  $saisies = array(
      array(
        'saisie' => 'explication',
        'options' => array(
          'li_class' => 'laclass',
          'texte' =>  'Bablabla blaaablabla blabal'
        )
      ),
  );
    return array('_saisies'=>$saisies);
  }

  dans formulaires/testou.html :

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

  et dans mon squelette :

  #FORMULAIRE_TESTOU

  ma config : spip 2.0.11 / plugins yaml et bonux activés

  • 

    RastaPopoulos

    Décembre 2010

    1. Oui pour le title ce serait intéressant
    2. Pour un tableau d’attribut ça serait plus compliqué car il faudrait alors gérer les collisions possible avec les attributs ayant leur option à part (comme la class, le title, etc). Et si on ne mettait QUE un tableau d’attributs pour qu’il n’y ait pas de collisions, c’est limite pire car c’est trop abstrait, contrairement aux options pour un attribut précis, ça n’aide pas les gens.
    3. Pour les boutons, ce n’est pas géré, en tout cas pour l’instant. Ça ne gère que le contenu du formulaire. Mais je suis d’accord que parfois pour des cas complexes on peut avoir besoin de boutons à l’intérieur même du formulaire et pas juste à la fin. Donc il faudrait effectivement rajouter les différentes possibilités de boutons existants. À ajouter à la todo.
    4. Pour la saisie explication... chez-moi-ça-marche :( Quel est le retour ? Une erreur, du vide complet, ou les balises <li> sans rien dedans ? Autre ?
  • 

    stefdn

    Décembre 2010

    merci pour ces réponses

    3. pour les boutons, j’ai créé un fichier submit.html dans squelettes/saisies/, en utilisant l’idée des attributs mais effectivement, ça reste délicats

    4. aucune erreur « visible », et rien de rien dans la page (et idem avec spip 2.1.2 et les plugins utiles) . Voilà ce que je trouve dans spip.log :

    (pid 5100) COMPIL (3.070 ms) [plugins/auto/saisies/saisies/fieldset.html]
     html_f8281334c0aeba79e3eb43416c90f732.php
    (pid 5100) calcul (0.108 ms) [plugins/auto/saisies/saisies/_base] 
    type_saisie=explication, li_class=laclass, texte='Bablabla blaaablabla blabal', lang=fr,
     date='2010-12-24 15:52:03', date_default=1, date_redac='2010-12-24 15:52:03', 
    date_redac_default=1 (2 octets)
    (pid 5100) Creation du cache d/sai-bas-exp-lac-Bab-arr--20b30930 pour 3600 secondes
    (pid 5100) charset probable: utf-8
    (pid 5100) trouver_table: table inconnue '' 'POUR'
    (pid 5100) COMPIL (7.056 ms) [plugins/auto/saisies/saisies/input.html] 
    html_f6706ef3175657d041b7a2476997ef68.php

  • 

    stefdn

    Décembre 2010

    Trouvé ! (?)

    j’ai ajouté l’option ’nom’ et ça passe. la description sur cette page m’aurait induit en erreur ? cette option est-elle systématiquement obligatoire pour tous types de champs ? ou bien ... ?

     array(
        'saisie' => 'explication',
         'options' => array(
             'nom' => 'explik', 
             'li_class' => 'laclass',
             'texte' =>  'Bablabla blaaablabla blabal'
         )
    )

    Ceci dit, j’ai d’autres soucis ... (o:

    j’appelle saisies_verifier($form) dans la fonction de vérification CVT et j’ai une fatal error :

    Fatal error: Call to undefined function saisies_verifier()...

    la fonction est pourtant dans inc/saisies.php ... et si je la copie dans mon fichier CVT ... re-fatal error qui paraît plus logique :

    Fatal error: Cannot redeclare saisies_verifier() (previously declared in /www/dev/spip/squelettes/formulaires/testou.php:196) in /www/dev/spip/plugins/auto/saisies/inc/saisies.php on line 442

    bon, faut dire que j’en suis à mon premier jour sur Saisies et j’ai pas encore tout compris (o;

  • 

    RastaPopoulos

    Décembre 2010

    Oui il faut l’option nom à toutes les saisies, ça permet de les identifier même si ce ne sont pas des champs.

    Pour vérifier 1) il faut évidemment d’abord inclure le fichier où se trouve l’API des Saisies, cad include_spip('inc/saisies');, et 2) si c’est pour vérifier plus que l’option obligatoire=oui, cad avec les descriptions de vérifications, là il faut le plugin « Vérifier ». Ça permet plus de choses.

  • 

    stefdn

    Décembre 2010

    ok merci ... j’avais oublié d’includer pfff...

    par contre, j’ai passé le tableau ($formulaire) des saisies en global, hors fonctions CVT pour que saisies_verifier($formulaire) retourne bien les erreurs, sinon, ne retourne rien (je n’ai pas compris comment passer en argument $formulaire à formulaires_monForm_verifier())
    Est-ce la bonne méthode ?

    j’ai bien le plugin Verifier et ça vérifie bien ... Mais ... en retour sur erreur les champs sont tous retournés vides (même si verifier n’est pas défini dans la saisie).

    j’ai essayé en ajoutant l’option defaut à mes saisies mais n’ai pas trouvé comment l’utiliser pour que les champs gardent leur valeur après vérification ...

  • 

    RastaPopoulos

    Décembre 2010

    Euh ça ça n’a sûrement rien à voir avec Saisies mais avec CVT. Vous avez bien déclarer les champs autorisés dans charger() ? Seuls les champs autorisés sont envoyés.

    Quand on déclare les saisies avec un tableau PHP, et qu’on en a besoin dans les 3 fonctions CVT (car dans traiter() aussi on en a souvent besoin), le mieux est d’écrire une fonction qui renvoie le tableau des saisies, et de l’appeler ensuite dans C, puis V, puis T. C’est un peu plus propre qu’une globale...

    J’ai déjà quelques idées pour améliorer encore l’API de Saisies et rendre tout ça automatique avec les CVT (du genre chercher automatiquement une fonction formulaires_truc_saisies()). Encore un truc qui est dans la todo list...

  • 

    stefdn

    Décembre 2010

    -  « Vous avez bien déclarer les champs autorisés dans charger() ? »

    - « a ben... non. Je-croyais-que le tableau des saisies servait aussi à ça » :$

    j’ai donc écrit une fonction qui retourne le tableau des saisies et l’ai ajouté à mon tableau de valeurs autorisées dans charger() ... maintenant tout passe : Merci RastaPopoulos :) !

    J’ai aussi trouvé un petit bug : je vais poster un ticket sur la zone et je pense que je peux écrire un petit tuto du genre Un formulaire avec Saisies par l’exemple !

  Répondre à ce message

• 

  JLuc

  Avril 2010

  J’ai créé une page sur le carnet wiki pour compléter la documentation et noter quelques remarques ... et peut être des interrogations aussi :

  http://www.spip-contrib.net/Doc-Sai...

  Pour l’instant y figurent des notes sur le mode d’emploi des boutons radio, des ’select’,... et sur les vérifications avec le plugin verifier.

  Répondre à ce message

• 2

  

  JLuc

  Avril 2010

  Mon but était de mettre 2 saisies côte à côte.

  Même en mettant les styles inline directement dans le formulaire.html qui appelle les saisies, je n’ai pas réussi.

  Pour que ça marche, il m’a fallu recopier localement TOUT le fichier habillage.css et en ajouter à la fin de ce fichier les propriétés ad hoc qui surchargent les valeurs spécifiées plus haut.

  Par exemple, pour un formulaire ’identite’ qui comporte une #saisie{input, prenom} immédiatement suivi d’une #saisie{input, nom}, pour que le nom apparaisse à droite du prénom, j’ai ajouté à la fin de habillage.css :

  .formulaire_identite .editer {
          float: left;
  }
  .formulaire_identite  .editer_prenom {
          clear: left; 
  }
  .formulaire_identite  .editer_nom {
          clear: right;
          margin-left: 10px;
  }

  Il faudrait peut être spécifier plus précisément pour faire plus générique, mais comme ça ça marche dans mon cas.

  Je m’étonne cependant de devoir recopier localement tout le habillage.css. ça me semble peu portable et je ne pense pas que ça soit la bonne pratique. En effet, dans le cas de la création d’un plugin ’identite’ (dans l’exemple), il est impossible de savoir si d’autres plugins n’ont pas déjà surchargé et modifié habillage.css, et dans un tel cas, le habillage.css fourni par ’identite’ sera en décalage...

  D’où ma question :
  Quelle est donc la bonne pratique pour personnaliser les CSS des saisies ?

  • 

    RastaPopoulos

    Avril 2010

    Mais de quoi tu parles ? Quel rapport en habillage.css et Saisies ? Et de quel habillage.css tu parles ? de la dist ? d’un site à toi ? de zpip ? autre ?

    Ce plugin n’a aucun rapport avec des CSS, il ne fait que générer du HTML. Après chaque site à ses styles, ce n’est aucunement du ressort de ce plugin.

  • 

    JLuc

    Avril 2010

    Désolé si ma question est un peu hors sujet, mais ya quand même un rapport puisque habillage.css (de zpip ou de la dist) style les formulaires spip, y compris ceux générés par SAISIE. D’ailleurs cet article l’évoque : Largeur (cols) : Largeur du bloc en nombre de caractères. Cette option n’est pas toujours appliquée car les styles CSS de votre site peuvent l’annuler. En effet, les indications CSS de habillage.css sont prioritaires par rapport aux attributs HTML générés par SAISIE.

    Or en CSS, il n’y a pas moyen d’annuler la valeur d’une propriété : on ne peut que la re-spécifier. En l’occurence, j’ai finalement trouvé comment faire sans recopier localement tout habillage : il suffit de créer un fichier perso.css et d’y mettre les propriétés CSS surchargées.

  Répondre à ce message

• 2

  

  JLuc

  Avril 2010

  Excellent plugin.

  Je remarque un truc étrange avec les textarea.
  Avec rows=2, il y a 3 lignes.
  Avec rows=5, il y a 6 lignes.
  Il faut rows=1 pour avoir 2 lignes,
  et rows=4 pour en avoir 5.

  Y a t il une raison ou bien c’est une erreur ?

  • 

    RastaPopoulos

    Avril 2010

    Ben non pas d’erreur, ça remplit directement le champs « rows » de la balise « textarea », donc ensuite c’est le navigateur qui fait ça...

  • 

    JLuc

    Avril 2010

    En effet. Merci Rastapopoulos

  Répondre à ce message

• 1

  

  poupougnac

  Avril 2010

  Salut RastaPopoulos,
  Merci pour Saisies qui m’aide particulièrement en ce moment. Je te fais part d’une fonction qui serait bien pratique pour formidable car j’en ai actuellement besoin et je constate que de nombreux formulaires proposent ce type d’option :
  -  Le fameux champs d’un menu en liste « autre » avec option de proposition dans un input si on le sélectionne, il devient dynamiquement éditable.
  -  L’incontournable champs date avec auto complétion

  -  Beaucoup plus audacieux mais je pense que c’est l’avenir et que prendre une longueur d’avance c’est une opportunité. L’auto-complétion d’adresse postale avec l’api de Google Map.
  Saisir une adresse est PENIBLE (adresse, ville, CP, Pays etc...)
  Ici il n’y a qu’un seul champs et Google retrouve l’adresse précise (et dans le monde entier).
  Test ici (en bas de page)
  et script déjà fait là :
  http://code.google.com/p/geo-autocomplete/

  Voila ces petites propositions qui pourrait rendre ton plugin très populaire.
  Merci pour ton travail.

  • 

    RastaPopoulos

    Avril 2010

    Merci pour les suggestions. Mais attention ce ne sont que des trucs avec javascript que tu proposes et il faut faire en sorte que les champs fonctionnent aussi sans. Des fois c’est possible, des fois pas, alors il faut bien réfléchir à comment les faire proprement.

  Répondre à ce message

• 1

  

  lili44300

  Mars 2010

  Bonjour,

  Question bête : existe-t-il une balise pour afficher le contenu renseigné par l’utilisateur dans les champs des balises #SAISIE ?
  Et une fois le formulaire envoyé, est-il traité par le plugin (on a la possibilité de définir par exemple un champ comme obligatoire, donc je suppose qu’un contrôle existe ensuite pour la validation), ou bien devons-nous nous-même le faire ?
  Merci d’avance pour ces quelques précisions ! :)

  Aurélie D.

  PS : pas mal comme plugin, ça simplifie drôlement la saisie des champs de formulaires, tâche ô combien rébarbative qui énerve tout développeur (qui se dit à chaque fois qu’il devrait prendre le temps de développer un petit truc maison, pour générer automatiquement les champs et les vérifications qui vont avec, mais qui faute de temps, se refade à chaque fois tout à la main... ^^).

  • 

    RastaPopoulos

    Mars 2010

    Ce n’est pas encore documenté mais il y a une balise #VOIR_SAISIE avec les mêmes paramètres, mais on lui passe aussi « valeur=truc ». Ça utilise alors les squelettes qui sont dans « /saisies-vues/ ».

    De la même façon il y a une balise #VOIR_SAISIES qui prend deux paramètres, d’abord le tableau de description comme #GENERER_SAISIES puis un autre tableau associatif avec les valeurs des champs (nom_du_champ=>valeur).
    Il faut que je complète la documentation avec ces balises.

    Sinon ce plugin est un outil pour développeur. C’est pas un générateur de formulaires. Pour ça il ya bientôt le plugin Formidable.

  Répondre à ce message

• 

  RastaPopoulos

  Mars 2010

  Je me pose la question Rasta de l’option « choix_destinataires ». Est-ce que ce serait possible d’utiliser « datas » comme les autres ? J’ai peur qu’on ait à un moment trop d’options spécifiques à une seule saisies. Qu’en penses tu ?

  Oui tu as raison.

  D’ailleurs pour aller plus loin, on pourrait renommer « datas » en « choix » (un truc comme ça, surtout que datas avec un s...). Mais en gardant la compatibilité bien sûr ! Il suffit de faire #ENV{choix, #ENV{datas}} et hop la compat est assuré avec l’existant.

  Alors si t’as un terme, je remplace à la fois tous les datas et le choix_destinataires.

  Répondre à ce message

• 

  Matthieu Marcillaud

  Mars 2010

  Roh, j’étais pas logé :) Je resigne : Matthieu.

  Répondre à ce message

• 1

  

  Shnoulle

  Mars 2010

  Excellent !!!

  Un grand merci !

  • 

    Mars 2010

    Je me pose la question Rasta de l’option « choix_destinataires ». Est-ce que ce serait possible d’utiliser « datas » comme les autres ? J’ai peur qu’on ait à un moment trop d’options spécifiques à une seule saisies. Qu’en penses tu ?

  Répondre à ce message