[spip-dev] Deuxième arg de #FORMULAIRE_INSCRIPTION quasi pas utilisé et surtout incohérent

[RastaPopoulos]

Le formulaire d'inscription est déclaré comme attendant
- un mode (en fait un statut uniquement par défaut)
- un id (un id quoi, on ne le sait pas)
- un URL de retour

Le deuxième argument est juste noté "id", nom peu judicieux qui
n'indique rien en soi.

Dans l'ordre d'utilisation :

1)
Cet id est passé à la fonction d'autorisation "inscrireauteur", et dans
les commentaires de cette fonction on apprend "Pour un statut et un
éventuel id_rubrique donné" : "id" serait en fait un "id_rubrique" !
Sauf que cette fonction dont on lit pourtant le commentaire n'utilise
absolument pas cet "id".

2)
Deuxième utilisation, dans l'étape verifier(), cet identifiant est passé
*directement en 4ème argument* à la fonction test_inscription_dist().
C'est évidemment censé être un entier positif ou nul.
Sauf que le 4ème argument de test_inscription_dist() est censé être un
tableau d'options !
Et là non plus, le fait qu'il y aurait un identifiant d'objet
(apparemment de rubrique) n'est jamais évoqué ni utilisé à cet endroit.

3)
Continuons dans l'incohérence, maintenant dans l'étape traiter(), cet id
est inséré *à l'intérieur d'un tableau* array('id'=>$id…), pour
l'envoyer à la fonction action_inscrire_auteur_dist() qui attend
effectivement un tableau d'options et qui va repasser celui-ci à la
fonction test_inscription_dist() dont on a parlé au 2). Et donc cette
fois ci en ayant balancé l'id à l'intérieur d'un bon tableau, et non
plus directement en 4ème argument comme dans verifier().

4)
Le troisième argument d'URL de retour est passé (en changeant son nom
pour "redirect") dans le tableau d'options de traiter() à
action_inscrire_auteur_dist(), mais celle-ci ne l'utilise jamais. Et
elle n'est jamais placé dans le tableau de retour du traiter() et donc
jamais utilisé par CVT.

Dites, ce serait pas complètement le bordel ?

Mention spéciale pour l'identifiant entier qui est parfois passé en
entier, parfois passé dans un tableau, à une fonction qui attend
toujours un tableau…

Instant constructif : m'est-avis que vu que cet identifiant n'est
apparemment utilisé nulle part, on pourrait d'ors et déjà dire que le
deuxième argument du formulaire pourrait devenir *toujours* un tableau
d'options. Et donc on passerait toujours un tableau à test_inscription.
Et tant qu'à faire, si on utilisait l'arg de retour qu'on propose
pourtant de fournir ?

À faire au moins en 3.3. Moi je le ferais directement en 3.2 car je
considère ça comme des bugs.

Vos avis ?

[c***@yterium.com]

Historiquement cet id est un id_rubrique pour l’inscription d’admin restreints
Il ne sert effectivement que trÚs peu, et possible que dans le refactoring de l’inscription il y ait eu de la perte au feu et des bugs introduits autour de cet id.
Possible aussi que j’avais essayé de le generaliser un peu considérant qu’il pouvait être utilisé pour autre chose dans les fonctions surchargées.
Il ne faut pas perdre de vue qu’il peut y avoir des fonctions surchargées (test_inscription notamment) dans la nature.

--
Cédric

Le formulaire d'inscription est déclaré comme attendant
- un mode (en fait un statut uniquement par défaut)
- un id (un id quoi, on ne le sait pas)
- un URL de retour
Le deuxiÚme argument est juste noté "id", nom peu judicieux qui
n'indique rien en soi.
1)
Cet id est passé à la fonction d'autorisation "inscrireauteur", et dans
les commentaires de cette fonction on apprend "Pour un statut et un
éventuel id_rubrique donné" : "id" serait en fait un "id_rubrique" !
Sauf que cette fonction dont on lit pourtant le commentaire n'utilise
absolument pas cet "id".
2)
DeuxiÚme utilisation, dans l'étape verifier(), cet identifiant est passé
*directement en 4Úme argument* à la fonction test_inscription_dist().
C'est évidemment censé être un entier positif ou nul.
Sauf que le 4Úme argument de test_inscription_dist() est censé être un
tableau d'options !
Et là non plus, le fait qu'il y aurait un identifiant d'objet
(apparemment de rubrique) n'est jamais évoqué ni utilisé à cet endroit.
3)
Continuons dans l'incohérence, maintenant dans l'étape traiter(), cet id
est inséré *à l'intérieur d'un tableau* array('id'=>$id
), pour
l'envoyer à la fonction action_inscrire_auteur_dist() qui attend
effectivement un tableau d'options et qui va repasser celui-ci à la
fonction test_inscription_dist() dont on a parlé au 2). Et donc cette
fois ci en ayant balancé l'id à l'intérieur d'un bon tableau, et non
plus directement en 4Úme argument comme dans verifier().
4)
Le troisiÚme argument d'URL de retour est passé (en changeant son nom
pour "redirect") dans le tableau d'options de traiter() à
action_inscrire_auteur_dist(), mais celle-ci ne l'utilise jamais. Et
elle n'est jamais placé dans le tableau de retour du traiter() et donc
jamais utilisé par CVT.
Dites, ce serait pas complÚtement le bordel ?
Mention spéciale pour l'identifiant entier qui est parfois passé en
entier, parfois passé dans un tableau, à une fonction qui attend
toujours un tableau

Instant constructif : m'est-avis que vu que cet identifiant n'est
apparemment utilisé nulle part, on pourrait d'ors et déjà dire que le
deuxiÚme argument du formulaire pourrait devenir *toujours* un tableau
d'options. Et donc on passerait toujours un tableau à test_inscription.
Et tant qu'à faire, si on utilisait l'arg de retour qu'on propose
pourtant de fournir ?
À faire au moins en 3.3. Moi je le ferais directement en 3.2 car je
considÚre ça comme des bugs.
Vos avis ?
--
RastaPopoulos
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

[RastaPopoulos]

Historiquement cet id est un id_rubrique pour l’inscription d’admin
restreints
Il ne sert effectivement que très peu, et possible que dans le
refactoring de l’inscription il y ait eu de la perte au feu et des bugs
introduits autour de cet id. 
Possible aussi que j’avais essayé de le generaliser un peu considérant
qu’il pouvait être utilisé pour autre chose dans les fonctions surchargées.
Il ne faut pas perdre de vue qu’il peut y avoir des fonctions
surchargées (test_inscription notamment) dans la nature.

Ok ok, mais donc comme ce sont deux types totalement différents, il doit
y avoir moyen très facilement d'ajouter un petit test et de prendre en
compte les anciens cas sans problème, non ?

if (!is_array($id_ou_options)) { …

Et du coup pour la suite, ce deuxième argument serait officiellement un
tableau.

Je fais ça en 3.3 ? 3.2 aussi car je considère que c'est un bug ?