Salut,
J'adore programmer.spip.org, mais j'aurais deux suggestions. Et comme je
ne connais pas les réponses, c'est pas bibi qui va écrire le truc. 
Je réponds rapidement, même s'il faudrait effectivement préciser ou ajouter des articles pérennes.
1. Comment est gérée la sécurité dans les formulaires, et quelles sont
les bonnes pratiques à respecter pour être «dans les clous»
(c'est-à-dire utiliser des fonctions SPIP qui, en théorie, font le
travail de sécurisation)?
Je vois deux points de ce côté:
- dans mon squelette de formulaire, est-ce que le fait de balancer les
#ENV** est suffisant, ou est-ce que ça peut laisse passer des injections
de machins? Si c'est toutotomatik, ça serait bien de l'indiquer.
À priori c'est le contraire. Les étoiles permettent de *désactiver* les filtres de sécurité appliqués automatiquement aux balises.
- quand je manipule la base de données avec les valeurs reçues depuis
les formulaires, qu'est-ce que je dois faire pour, encore une fois,
rester dans les clous? sql_selectq, sql_updateq, ça fait quoi?
Les versions "q", signifient "quote", c'est-à-dire qu'elles vont automatiquement échapper proprement les valeurs. Il existe une version automatique avec sql_insertq et sql_updateq. Par contre pour les select il faut échapper à la main les valeurs avec la fonction sql_quote(). Pour les valeurs entières, je crois qu'un intval($valeur) suffit.
2. Que faire après le traitement du formulaire? Bon, OK, bidouiller la
base de données. Mais après? Comment je vais quelque part ou comment je
fais un Ajax quelconque? Quelles sont les méthodes préconisées.
C'est le paramètre "redirect" du tableau de retour de la fonction traiter().
Parce que de mon côté, sans doc là dessus, je reste dans la bidouille,
alors que je suis certain que c'est super-propre et super-facile.
Exemples:
- à la fin du traitement du formulaire, je veux changer de page. Hop:
header. Mais: (1) c'est capricieux, (2) avec {ajax} ça ne passe pas;
Donc $retours['redirect'] = une url
C'est censé marcher dans tous les cas, mais en ce qui me concerne je n'ai jamais réussi à le faire fonctionner avec <div class="ajax"> autour du formulaire.
En fait ça fonctionne, SPIP détecte bien qu'il faut rediriger vers la page, mais il ne le fait pas automatiquement. Ça ajoute le message : "Cette page va être rediriger, si ça ne le fait pas automatiquement, cliquez ici". C'est toujours mieux que rien, mais pas entièrement satisfaisant.
Je crois que me rappeler que Cédric m'avait dit que le javascript s'occupant de l'ajax devait capter la demande de redirection et renvoyer alors vers la page, mais peut-être que ça marche sur la version en développement...
- à la fin de mon traitement, je veux déclencher un javascript (genre:
afficher illico un nouveau message dans la page).
Dans tous les cas il y a un rechargement du formulaire, donc à priori le message à afficher peut l'être grâce aux deux variables :
[<p class="reponse_formulaire reponse_formulaire_ok">(#ENV*{message_ok})</p>]
[<p class="reponse_formulaire reponse_formulaire_erreur">(#ENV*{message_erreur})</p>]
En effet, soit ya pas de <div class="ajax"> et donc la page se recharge entièrement (et le formulaire avec), soit ya au moins le formulaire lui-même qui se recharge.
Si tu veux afficher une message genre "petite boite flottante qui apparait en fondu, et disparait au bout de quelques secondes", et bien ça ne change pas grand chose, ça serait juste du javascript à ajouter au squelette du formulaire. Mais tout se passe dedans.
- en fin de formulaire: comment je fais pour détruire le cache de la
page qui est en train d'appeler le formulaire?
Depuis un certain temps déjà, il n'y a plus de système d'invalidation permettant de cibler un squelette précis à recalculer.
On peut donc faire :
include_spip('inc/invalideur');
suivre_invalideur(true);
Ce qui supprime tout le cache, je crois.
Si tu veux juste recalculer la page sur laquelle le formulaire est appelée, alors il faut ajouter un "var_mode=recalcul" à la page du "redirect". Mais un simple visiteur ne pourra pas recalculer, il me semble.
