Formidable Présentation aux Grottes (2010)

Présentation du plugin par Rastapopoulos à la Troglo Spip : le 14 Mai 2010

Prises de Notes : Nat33 & Loiseau2nuit

Généralités :

but :
L’objectif était de créer un plugin permettant de générer des formulaires. Historiquement, 2 plugins avaient déjà été développés précédemment pour remplir cette fonction
-  Form &Table, qui n’a pas été complètement porté pour spip 2
-  et spip formulaire créé par artego mais qui n’est plus maintenu.

La question s’est donc posée : construire sur la base d’un des 2 plugins ou repartir de zéro ?
Form &Table présentait l’inconvénient d’avoir un côté « fourre-tout » qui le rendait difficilement modifiable et difficile à personnaliser par les développeurs.

Il a finalement été décidé de repartir de zéro pour proposer quelque chose

• de plus facile à utiliser pour les utilisateurs d’une part ,
• mais aussi de plus facile à personnaliser pour les développeurs.
  avec le parti pris de se baser de préférence sur plusieurs petits plugins spécialisés et de tirer parti de la nouvelle norme CVT

Base :
CVT (c’est *LA* grosse amélioration par rapport à F&T)

Trois petits plugins séparés proposent les trois fonctions nécessaires à la gestion des formulaires CVT
-  Charger → saisies
-  Vérifier → vérifier
-  Traiter → yaml ?

Le plugin Formidable a voulu englober et enrichir les fonctionnalités de ces trois plugins.
L’API de vérifier, par exemple, peut être utilisée pour ajouter des choses : il y a un fichier par type de vérification, il est donc très facile d’ajouter un nouveau type de vérification en ajoutant un fichier .
Dépendances :

Saisies, Vérifier, yaml…

Télécharger :

• Lien direct : http://files.spip.org/spip-zone/formidable.zip
• Par SVN : svn co svn://zone.spip.org/spip-zone/_plugins_/formidable

Mise en oeuvre dans SPIP

Après avoir installé le plugin, l’interface de configuration et de création de formulaire est accessible dans le Menu EDITION > FORMULAIRES

La première page liste les différents formulaires déjà créés disponibles et affiche un bouton « Créer un nouveau formulaire »
La création est découpée en plusieurs étapes

1. Configurer le formulaire
2. Configurer les champs
3. Configurer les traitements

1^re étape : Configurer le formulaire

Titre  : libellé en clair du formulaire

Identifiant : identifiant textuel unique permettant d’appeler le formulaire dans les squelettes et les articles de facile plus directement intelligible.
Comme pour le plugin menu, on estime que le nombre de formulaires, comme de menu n’est pas aussi important que pour les autres objets éditoriaux et ne justifie pas de préférer un ID numérique.
Il est précisé également que lors d’opérations d’import / export ou de restauration, l’Id numérique peut doublonner et être à l’origine d’un écrasement du formulaire et ou des données collectées.

Message de retour : Le message affiché après à la validation du formulaire

Descriptif : ce champs ne s’affiche que dans l’espace privé. Il sert à décrire le formulaire dans la liste des formulaires.

Dans tous les champs il est possible d’utiliser les champs multi et/ou des chaines de langue.

2^e étape : : Configurer les champs du formulaire

à ce stade de la création, il n’y a encore aucun champ dans notre formulaire.

Une liste de type de champs est proposée :
-  case à cocher
-  bouton radio
-  ligne de texte
-  liste de choix...

NB un message apparaît mettant en garde l’utilisateur que des modifications ont été opérées et ne sont pas encore sauvegardées.
« Le formulaire ci-dessous est différent du formulaire initial. Vous avez la possibilité de le réinitialiser à son état avant vos modifications ».
En effet le travail de l’utilisateur sur le formulaire n’est pas encore enregistré en Base mais uniquement dans une session.
Tant qu’il n’a pas appuyé sur le bouton enregistré les modifications ne sont pas enregistrées définitivement. Aussi l’utilisateur a la possibilité de réinitialiser le formulaire pour le restaurer à son état initial si il ne souhaite pas conserver ses modifications.

Au survol, le nouveau champ choisi apparaît tout de suite en wisiwyg
2 boutons d’action sont proposés à l’utilisateur : [Édition/configuration] [suppression]

le clic sur le bouton « édition » charge un formulaire de configuration du champ.

Tout est configurable, beaucoup d’options sont proposées, aussi elles ont été réparties dans 4 onglets
Les options proposées varient bien entendu en fonction du type de champ

Description / Utilisation / Affichage / Validation

• • Description
    permet de déterminer la position du champ dans le formulaire, son libellé, la valeur par défaut, le cas échéant un message d’explication

• • Utilisation
    on défini ici le nombre de caractères, on active ou pas le focus sur le champs

• • Affichage
    permet d’ajouter une class css , de changer le libelle du message permettant d’identifier les champs obligatoires. Il est possible d’insérer des multi et des chaines de langue

• • Validation
    détermine le caractère obligatoire ou non et et les vérifications de format à effectuer dur le champs.

On clique sur le bouton [enregistrer] pour sauvegarder la configuration du champ.

Le champ apparaît alors comme il sera au final. Le plugin saisie génère le html affiché dans l’espace privé comme dans l’espace public. Il peut facilement recevoir un style via la css.

Attention : le formulaire n’est pas encore sauvegardé dans la base à ce stade. Il faut cliquer sur le bouton [enregistrer]

3^e étape : : Configurer les traitements du formulaire

Les deux traitements proposés par défaut à ce stade du développement sont :
-  l’envoi de la réponse par courriel
-  la sauvegarde des résultats

Il est possible pour les développeurs d’en ajouter d’autres.

Le choix de l’envoi par courriel affiche les options à préciser
-  le mail du destinataire ( soit choix d’un champ, soit déclaration en dur) Edit 29/07/2010 nat33 : il est désormais possible de récupérer un auteur de l’environnement pour renseigner le destinataire. créer un champ hidden, renseigner l’id_auteur via un paramètre dans l’appel du formulaire, choisir ce champ hidden comme destinataire du formulaire. Par exemple : #FORMULAIRE_FORMIDABLE{contact, #ARRAY{hidden_1, #ID_AUTEUR}}
-  courriel de l’envoyeur
-  le nom de l’envoyeur
-  sujet du message

Il est possible d’ajouter un Accusé de réception

Il est précisé que les mails envoyés en retour aux visiteurs sont développés sous forme de squelettes et peuvent donc être entièrement personnalisés par le webmestre qui peut tout simplement placer un squelette personnalisé dans son dossier squelette. L’utilisation de l’identifiant textuel permet en outre de créer un squelette de formulaire personnalisé différent par formulaire .

Synthèse / CVT

Jouer avec les résultats

Dans le back office :
(en appoint des resultats evtl. Envoyés par mail, elles se stockent aussi en base et sont donc consultables/manipulables(via crayons evtl.) depuis le B.O. (pour alimenter le contenu d’un article-sondage par exemple...)

Quid des portes ouverte vers des plugs de graphisation des résultats par exemple (Tex, LaTex, Export2Excel, ... ?) => Export des réponses possible en CSV !

Dans les squelettes

S’appelle comme un modèle ds le texte de ses contenu ou via une balise

 !!! : il paraitrait qu’il vaut mieux cibler le form qu’on appelle avec son identifiant textuel plus qu’avec son identifiant numérique qui peut changer en cas de restauration des données.

Liste des fichiers stratégiques et surchargeables :

Évolution

• Pour le moment : un peu brut de décoffrage mais Jquery-isation de l’interface prévue pour améliorer l’exp. Utilisateur (drag & drop etc... <=> Jquery UI ???)

• Peut-on envisager des « templates » de formulaires, qui reprendraient les champs souvent récurents d’un type de form à l’autre, auquel l’utilisateur pourrait ajouter/supprimer des champs... => duplication de formulaire ! Sinon, les prochaines versions seront livrées avec 1 ou 2 formulaires type afin de servir d’exemple : 1 contact, 1 sondage, ...)

• A terme, en ajoutant les traitements qui vont bien, on pourrait envisager de créer un form de recherche avancée dans SPIP par exemple...

Conclusion

En très gros on retrouve pour l’essentiel les fonctionnalités qui marchent de F&T mais entièrement remises au goût du jour.

• Une meilleure intégration
• Meilleure prise en charge dans les forms des #BALISES et des <:chaine_langues :> (pas forcément possible avec F&T de mémoire...)

Mais pas la possibilité de passer des variables avec la balise d’appel du formulaire (ce qui est très pratique avec F&T), Formidable limite aux contenus de champs…

L’idée d’utiliser CVT pour gérer les différentes phase est d’éviter au max. l’utilisation de méthode de vérif en JS qui n’apportent plus gd chose (sauf .ajax qui permettent d’accélérer le retour-écran des infos (qui du coup ont déjà été vérifiées en amont))

Afficher les résultats dans spip

formidable fournit un modèle prédéfini pour afficher les résultats : "formulaires_reponse".
http://zone.spip.org/trac/spip-zone/browser/_plugins_/formidable/modeles/formulaires_reponse.html

Il est également possible d’aller chercher les résultats pour les présenter de la manière voulue :

<b_numero_reponse>
<ul>
  <boucle_numero_reponse(spip_formulaires_reponses)>
  <li>reponse #ID_FORMULAIRE_REPONSE : <br>
  <boucle__reponses_champ1 (spip_formulaires_reponses_champs){nom=textarea_1}>#VALEUR</boucle_reponse_champ1>
  -
  <boucle__reponses_champ2 (spip_formulaires_reponses_champs){nom=textarea_2}>#VALEUR</boucle_reponse_champ2>
  -
  <boucle__reponses_champ3 (spip_formulaires_reponses_champs){nom=input_1}>#VALEUR</boucle_reponse_champ3>
  </li>
  </boucle_numero>
</ul>
</b_numero_reponse>

Pour ça il faut connaitre le nom interne de chaque champ dans formidable : input_1, ...

C’est par contre plus compliqué pour faire directement à partir du name du champ car la correspondance avec le nom internet passe par une sérialisation dans le champ saisies de la table spip_formulaires. A moins qu’il n’y ait un filtre standard pour faire la correspondance...