Mutualiser tous les parsings de recherche de valeur si le nom de champ est un tableau #29

Closed
opened 2 years ago by rastapopoulos · 3 comments
Owner

Il y a je ne sais combien de fois le même parsing de recherche si le champ est de la forme nom[index][index].

Parfois c'est pas pour chercher dans GET/POST, mais ce n'est pas une raison : _request() permet depuis toujours de chercher dans un autre tableau !

Donc saisies_request() devrait pouvoir le prendre et le transmettre aussi. Et toutes les utilisations devraient appeler cette fonction au lieu de refaire le parsing 12 fois. Dès qu'on cherche la valeur d'un champ, dans GET/POST ou dans un $env qu'on a sous la main, c'est cette fonction qui devrait être appelée. Là en plus de dupliquer le code, ya des oublis, comme dans #28 par ex.

Au passage : il manque aussi que les noms de champs peuvent aussi être de la forme "nom/index/index" (possibilité ajouté par @marcimat un jour) mais qui en fait n'est pas pris en compte dans un grand nombre de cas, dont toutes ces recherches de valeur à priori. Le fait de toujours mutualiser, ça fait qu'ensuite si on le prend en compte dans saisies_request(), ça sera partout.

Au passage 2 : ça n'a aucune spécificité à Saisies, n'importe quel formulaire peut avoir des champs en tableau. J'aurais donc envie de proposer que ce soit ajouté au _request() du core, car je ne vois aucun cas où on chercherait la valeur d'un nom de champ qui contiendrait réellement les caractères "/" ou "[". Ça ne peut pas exister normalement ! Donc dès qu'il y a ça dans _request(), on devrait pouvoir dire que qu'il faut parser et chercher dans un sous-tableau, dans le core. Il n'y aurait alors plus besoin de saisies_request().

Il y a je ne sais combien de fois le même parsing de recherche si le champ est de la forme `nom[index][index]`. Parfois c'est pas pour chercher dans GET/POST, mais ce n'est pas une raison : _request() permet depuis toujours de chercher dans un **autre** tableau ! Donc saisies_request() devrait pouvoir le prendre et le transmettre aussi. Et toutes les utilisations devraient appeler cette fonction au lieu de refaire le parsing 12 fois. Dès qu'on cherche la valeur d'un champ, dans GET/POST ou dans un $env qu'on a sous la main, c'est cette fonction qui devrait être appelée. Là en plus de dupliquer le code, ya des oublis, comme dans #28 par ex. Au passage : il manque aussi que les noms de champs peuvent aussi être de la forme "nom/index/index" (possibilité ajouté par @marcimat un jour) mais qui en fait n'est pas pris en compte dans un grand nombre de cas, dont toutes ces recherches de valeur à priori. Le fait de toujours mutualiser, ça fait qu'ensuite si on le prend en compte dans saisies_request(), ça sera partout. Au passage 2 : ça n'a aucune spécificité à Saisies, n'importe quel formulaire peut avoir des champs en tableau. J'aurais donc envie de proposer que ce soit ajouté au _request() du core, car je ne vois aucun cas où on chercherait la valeur d'un nom de champ qui contiendrait réellement les caractères "/" ou "[". Ça ne peut pas exister normalement ! Donc dès qu'il y a ça dans _request(), on devrait pouvoir dire que qu'il faut parser et chercher dans un sous-tableau, dans le core. Il n'y aurait alors plus besoin de saisies_request().
Poster
Owner
Pour le noyau : https://core.spip.net/issues/4548
Owner

A l'époque j'avais demandé pour set_request

https://core.spip.net/issues/4110

A l'époque j'avais demandé pour set_request https://core.spip.net/issues/4110
Owner

On ferme. Tu a créé saisies_request() et saisies_set_request(). On sait que cela existe. Reste encore quelques cas où il faut sans doute faire appelle à ces fonctions, mais c'est à voir au cas par cas.

On ferme. Tu a créé saisies_request() et saisies_set_request(). On sait que cela existe. Reste encore quelques cas où il faut sans doute faire appelle à ces fonctions, mais c'est à voir au cas par cas.
maieul closed this issue 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.