[spip-dev] Inscription forcée en AJAX et pas de redirection possible

Dev
1

Pourquoi ?

La classe CSS "ajax" est forcée à l'intérieur du squelette du formulaire, alors que normalement c'est à chacun de mettre <div class="ajax"> autour des formulaires qu'on choisit.

Et si on veut que la page se recharge entièrement quand on a fini de s'inscrire, on est obligé de surcharger tout le squelette, en perdant les mises à jour plus tard ?

Que SPIP n'ait pas à prévoir les utilisations des gens ok, mais il n'a pas non plus à imposer un CVT en AJAX alors que normalement c'est à chacun de choisir à l'extérieur de l'appel.

Il faudrait penser à enlever ça en 3.2 au moins, non ?

(Par ailleurs, quasiment tous nos formulaires ont un paramètre "redirect" possible lors de l'appel en squelette, mais PAS celui d'inscription : impossible du coup de rediriger facilement les utilisateurices où on le désire une fois fini que ce soit #SELF ou autre part. Ça mériterait un ajout aussi, à mon avis.)

2

RastaPopoulos a écrit :

Pourquoi ?

La classe CSS "ajax" est forcée à l'intérieur du squelette du
formulaire, alors que normalement c'est à chacun de mettre <div
class="ajax"> autour des formulaires qu'on choisit.

Et si on veut que la page se recharge entièrement quand on a fini de
s'inscrire, on est obligé de surcharger tout le squelette, en perdant
les mises à jour plus tard ?

Que SPIP n'ait pas à prévoir les utilisations des gens ok, mais il n'a
pas non plus à imposer un CVT en AJAX alors que normalement c'est à
chacun de choisir à l'extérieur de l'appel.

Il faudrait penser à enlever ça en 3.2 au moins, non ?

(Par ailleurs, quasiment tous nos formulaires ont un paramètre
"redirect" possible lors de l'appel en squelette, mais PAS celui
d'inscription : impossible du coup de rediriger facilement les
utilisateurices où on le désire une fois fini que ce soit #SELF ou autre
part. Ça mériterait un ajout aussi, à mon avis.)

Là encore, ton problème est que tu réutilises les composants du core pour quelque chose pour lequel ils n'ont pas été prévu. L'inscription, telle que pensée dans le core, se fait en 2 étapes : 1 remplissage formulaire + un email

On peut refondre, repenser, étendre tout cela dans la version dev, pour faire quelque chose de plus générique, polyfonctionnel etc.

Mais ce qui existe résulte de choix assumés et est cohérent, en ce sens ce n'est pas défectueux.

3

Mais encore ? :slight_smile:

Ça ne répond pas à la question : c'est quoi la raison logique et rationnelle pour obliger les gens à ce que ce formulaire-là soit toujours en AJAX, alors que tous les autres formulaires permettent à chacun⋅e de choisir ou pas, lors de l'appel, en mettant un div autour soi-même ?

Je ne vois absolument pas où est la cohérence justement. On a une manière de fonctionner, documentée pour tous les CVT, ça doit justement marcher pareil partout.

Si dans la dist on veut que ça ne recharge pas la page, et bien on met <div class="ajax"> dans la colonne où est appelé ce formulaire, c'est comme ça que ça fonctionne normalement.

4

Un tour d'archéologie rapide autour de r11954 et tu verrais que ce n'est pas le seul formulaire dans ce cas. Il y a au moins autour de cette série de modifications le formulaire 'ecrire_auteur', et le formulaire 'site' avec lui.

Sans réellement pouvoir présager de la volonté derrière j'imagine bien le scénario suivant : ces formulaires sont utilisés dans divers squelettes publics (ce ne sont pas des formulaires dans prive/ pour l'espace ecrire/). Cette modification permettait à tous les squelettes existants de bénéficier du mode ajax pour ces formulaires sans rien modifier à leur code. Et ça, c'est vachement gentil.

Je suis circonspect du coup sur le déplacement du "ajax" en dehors de ces formulaire pour cette version 3.2. Ceci dit, 1) cela permettrait d'harmoniser comme tu dis, et 2) cela pourrait être quelque chose d'annoncé clairement en sachant par ailleurs que ça ne devrait pas casser le fonctionnement des sites existants (juste perdre l'ajax).

MM.

5

hello,

est-ce que seuls ceux qui ont surchargé le formulaire perdraient l’ajax ou j’ai mal compris ?

6

Je suis toujours pour enlever cet ajax forcé à l'intérieur du
formulaire, et de n'importe quel autre formulaire qui fait ça. Et je ne
suis d'accord avec aucun des arguments de Cédric que ce soit pour l'ajax
ou pour la redirection, et cela même pour le comportement par défaut de
SPIP avec l'email de confirmation (pas mon cas perso où je connecte
directement les gens).

## Pour l'ajax forcé

Tous les formulaires doivent avoir un fonctionnement cohérent, et c'est
documenté qu'on doit le mettre AUTOUR.

Et quand on ne veut pas ça, on ne doit pas être obligé de surcharger
entièrement le squelette et donc perdre toute évolution future, tout ça
pour enlever un "ajax" dans la class…

J'avais signalé ça avant la 3.2 qui était encore en dev à ce moment, et
on aurait pu l'enlever de la 3.2 et le signaler dans la doc de version.
Du coup là je suis toujours pour l'enlever aussi vite que possible, et
le documenter dans la doc de version.

## Pour la redirection non prévue

Pour ce qui est de la redirection, je ne suis pas d'accord non plus :
*même* quand on oblige les gens à aller confirmer dans leur email, ça
n'empêche absolument pas qu'on peut vouloir les rediriger sur une page
spéciale quand ils viennent de s'inscrire ! Ça n'a strictement aucun
rapport avec le fait de confirmer son inscription (et ça n'a pas de
rapport non plus avec la page sur laquelle ils pourraient arriver après
confirmation).

Exemple parfaitement possible :

Formulaire d'inscription => redirection sur une page explicative ("Vous
venez de vous inscrire, il va se passer ci ou ça, vous devez confirmer
blabla") => Aller dans mes emails => Cliquer le lien de confirmation =>
Redirection sur encore une autre page différente ("Vous venez de
confirmer, c'est super maintenant vous avez accès à ci ou ça").

## Conclusion

1) Pas d'ajax obligatoire par défaut.

2) Le formulaire d'inscription doit permettre de rediriger
optionnellement vers n'importe quelle page comme tous les autres CVT de
SPIP, dès la fin de son traitement. Cohérence.

3) Le formulaire d'inscription doit permettre de rediriger
optionnellement sur une page précis après avoir cliqué sur le lien de
confirmation dans l'email, et ce n'est pas forcément la même page
qu'après le traitement ! Donc par un autre argument/option.
=> c'est ce qu'a fait peetdu mais au mauvais endroit, car l'argument
utilisé devrait l'être pour le point 2) par cohérence avec tous les
autres formulaires, ce n'est ni utilisé ni documenté, donc on peut
encore le changer pour privilégier la cohérence (cf le fil du 11/02)