Produits Entr'ouvert » w.c.s.

Ça sera tellement pas utilisé ailleurs que pour #27302, ne peut-on pas construire une variable de traitement de type fichier (via un peu de Python) puis l'envoyer en fichier attaché ?

Et je me réponds à moi-même, que ça pose certainement un soucis de récursivité :/ (la variable faisant partie elle-même du json)

Donc autre idée, parce que le format en dictionnaire de __to_json_attachment m'ennuie un peu : avoir plutôt un PicklableUpload ?

Thomas Noël a écrit :

Ça sera tellement pas utilisé ailleurs que pour #27302, ne peut-on pas construire une variable de traitement de type fichier (via un peu de Python) puis l'envoyer en fichier attaché ?

On a base64 dans le global_eval_dict ? Je n'en ai pas l'impression, difficile de créer un export fichier dans ce cas (je pense qu'il faudrait plutôt publier un constructeur facile à utiliser genre json_attachment(filename, content_type, content).

Et je me réponds à moi-même, que ça pose certainement un soucis de récursivité :/ (la variable faisant partie elle-même du json)

Hein ?

Donc autre idée, parce que le format en dictionnaire de __to_json_attachment m'ennuie un peu : avoir plutôt un PicklableUpload ?

Oui aucun souci, c'était plus court de passer par le format JSON qui est de toute façon parfaitement supporté par FileField.convert_value_from_anything() mais bon si tu préfères (le code sera plus long il me semble).

PS: finalement je reste au format JSON, PicklableUpload ne marche pas dans ce cas là (c'est une abstraction pourrie, get_content() retourne None, parce que tant qu'il a pas été picklé, PicklableUpload n'est pas dans un état fonctionnel :/, un PicklableUpload juste initialisé n'ayant pas d'attribut 'qfilename', PicklableUpload.get_content() retourne toujours None)

On a base64 dans le global_eval_dict ?

Si on l'avait, ça permettrait de faire quelque chose sans modification à variables.py ? (parce que ça semble quand même de l'ultra-spécifique, qui ne sera jamais réutilisé).

json_attachment(filename, content_type, content)

Ou bien ça, ou plutôt juste attachment(content, filename='', content_type='application/octet-stream'), mais même question qu'au-dessus, on a le nécessaire en variables pour ensuite faire =attachment(form.export_to_json(include_files=True)) ?

Frédéric Péters a écrit :

On a base64 dans le global_eval_dict ?

Si on l'avait, ça permettrait de faire quelque chose sans modification à variables.py ? (parce que ça semble quand même de l'ultra-spécifique, qui ne sera jamais réutilisé).

Non comme tu le décèles plus loin on n'a pas accès aux méthodes de FormData depuis LazyFormData.

json_attachment(filename, content_type, content)

Ou bien ça, ou plutôt juste attachment(content, filename='', content_type='application/octet-stream'), mais même question qu'au-dessus, on a le nécessaire en variables pour ensuite faire =attachment(form.export_to_json(include_files=True)) ?

Non. Je propose de partir sur un as_json/as_json_with_files qui appelle simplement export_to_json et un helper utils.attachment() comme tu le proposes, est-ce que ça irait à tout le monde ?

Tu incluerais dans ton test un content_type='application/json' pour l'un des deux attachements, pour tester ça ?

Mais aussi, je regarde et form.formdata devrait te donner accès au formdata brut, et du coup l'export_to_json devient accessible. (l'accès direct aux objets n'est pas quelque chose que je voudrais encourager mais ça nous donne davantage de temps pour réfléchir à ce qu'on veut comme nouvelles méthodes/propriétés sur LazyFormdata).