[SPIP Zone] spip-listes : patron message en format texte

Archives Zone
1

bonjour,

j'ai cru comprendre (mais je me suis peut-être trompé, d'où ce
message) en regardant le code que s'il existe un patron format texte
(nom avec _texte) il est pris en compte pour "fabriquer" la version
texte du message. Exact ?

Mais j'ai l'impression que ça ne marche pas. D'ailleurs, j'ai essayé
de générer un message avec le patron portfolio livré avec spip-listes
qui a une version portfolio_texte et il me semble que la version texte
est fabriquée à partir du mail html et non du patron ad hoc.

Y a un bug, non ?

Le test est réalisé avec spip-listes "du jour" et spip 1.9.2

merci d'avance,
christophe

2

En ce qui concerne SPIP-Listes 193 :

Soit le patron est au format HTML, soit il est au format texte. C'est-à-dire
que dans le premier cas, ce patron est 'construit' avec du code HTML. Et
dans le second cas, ce patron est 'construit' sans élément HTML.

Dans les deux cas, il est 'construit' par son créateur, le nom du fichier
n'est pas interprété par SPIP-Listes. SPIP-Listes ne voit là qu'un patron,
rien de plus.

Je répète le mot 'patron' volontairement, pour bien faire le distinguo avec
les préférences de réception. Si vous construisez un 'patron' au format XML,
'portfolio_xml' ne sera guère qu'un 'patron', un squelette de plus.

Le nom de fichier du patron n'influe en rien sur le format final de
réception choisi par l'abonné (HTML ou texte seul).

Ensuite, la trieuse (la fonction de SPIP-Listes qui a en charge la
construction du message) se charge de récupérer le patron (via
recuperer_fond()). Et c'est la meleuse qui prend la main (la fonction de
SPIP-Listes qui a en charge la distribution du message). La meleuse
construira à son tour une version 'texte seul' - à partir du résultat
préparé par la trieuse - pour les abonnés souhaitant le format de réception
'texte seul'.

Au final, il est prévu que chaque abonné puisse s'abonner à chaque liste
dans un format pas forcément identique à sa préférence globale
(spip_auteurs_elargis.spip_listes_format). La table 'spip_auteurs_listes' -
table des abonnements - propose un champ 'format' qui peut servir à ça.

En espérant avoir apporté la réponse.

Bon courage.

-----Message d'origine-----
De : spip-zone-bounces@rezo.net
[mailto:spip-zone-bounces@rezo.net] De la part de christophe le drean
Envoyé : dimanche 23 novembre 2008 00:28
À : spip-zone@rezo.net
Objet : [SPIP Zone] spip-listes : patron message en format texte

bonjour,

j'ai cru comprendre (mais je me suis peut-être trompé, d'où ce
message) en regardant le code que s'il existe un patron format texte
(nom avec _texte) il est pris en compte pour "fabriquer" la version
texte du message. Exact ?

Mais j'ai l'impression que ça ne marche pas. D'ailleurs, j'ai essayé
de générer un message avec le patron portfolio livré avec spip-listes
qui a une version portfolio_texte et il me semble que la version texte
est fabriquée à partir du mail html et non du patron ad hoc.

Y a un bug, non ?

Le test est réalisé avec spip-listes "du jour" et spip 1.9.2

merci d'avance,
christophe
_______________________________________________
spip-zone@rezo.net -
http://listes.rezo.net/mailman/listinfo/spip-zone

3

Le 23 novembre 2008 18:24, Christian Paulus <paladin@quesaco.org> a écrit :

En ce qui concerne SPIP-Listes 193 :

Soit le patron est au format HTML, soit il est au format texte. C'est-à-dire
que dans le premier cas, ce patron est 'construit' avec du code HTML. Et
dans le second cas, ce patron est 'construit' sans élément HTML.

Dans les deux cas, il est 'construit' par son créateur, le nom du fichier
n'est pas interprété par SPIP-Listes. SPIP-Listes ne voit là qu'un patron,
rien de plus.

Je répète le mot 'patron' volontairement, pour bien faire le distinguo avec
les préférences de réception. Si vous construisez un 'patron' au format XML,
'portfolio_xml' ne sera guère qu'un 'patron', un squelette de plus.

Le nom de fichier du patron n'influe en rien sur le format final de
réception choisi par l'abonné (HTML ou texte seul).

ok, mais ce n'était pas ça ma question. C'était sur la manière dont
est produit la version html et la version texte d'un même message.

Ensuite, la trieuse (la fonction de SPIP-Listes qui a en charge la
construction du message) se charge de récupérer le patron (via
recuperer_fond()). Et c'est la meleuse qui prend la main (la fonction de
SPIP-Listes qui a en charge la distribution du message). La meleuse
construira à son tour une version 'texte seul' - à partir du résultat
préparé par la trieuse - pour les abonnés souhaitant le format de réception
'texte seul'.

c'est là où je ne suis pas certain de bien comprendre ce que tu
expliques par rapport au début de ton message : le format texte est
fait en fonction de quoi ? du patron version html (par exemple
portfolio.html) débarassé de son code html pour n'en garder que du
texte (il me semble que c'est ça qui se passe et ce que tu décris ici)
ou bien du patron en format texte (disons par exemple
portfolio_texte.html, et là, si je comprends bien ça colle avec ce que
tu expliques au début de ton message) ?

Si c'est la première solution, mais alors à quoi sert le patron
portfolio_texte qui disponible avec Spip-listes ?

Ou bien je ne comprends pas ce que tu expliques.

Ou bien il est possible d'appliquer un patron version html et version
texte, et dans ce cas, ça ne marche pas.

désolé, je veux bien qu'on me dise que je suis bas du plafond, mais là
c'est pas clair...

christophe

4

Christian Paulus a écrit :

En ce qui concerne SPIP-Listes 193 :

Soit le patron est au format HTML, soit il est au format texte. C'est-à-dire
que dans le premier cas, ce patron est 'construit' avec du code HTML. Et
dans le second cas, ce patron est 'construit' sans élément HTML.

Dans les deux cas, il est 'construit' par son créateur, le nom du fichier
n'est pas interprété par SPIP-Listes. SPIP-Listes ne voit là qu'un patron,
rien de plus.

Je répète le mot 'patron' volontairement, pour bien faire le distinguo avec
les préférences de réception. Si vous construisez un 'patron' au format XML,
'portfolio_xml' ne sera guère qu'un 'patron', un squelette de plus.

Je crois que tu as détourné l'esprit dans lequel cette fonctionnalité a été implémentée et fonctionnait dans Spip Listes pour SPIP 1.9.2 :
un patron monpatron.html est toujours censé générer une newsletter html, mais il est possible de proposer une variante monpatron_texte.html qui sera justement utilisée pour envoyer la version texte aux abonnés qui ont demandé à recevoir une version texte.

La transformation automatique html->texte est intéressante comme fonctionnement par défaut mais ne saurait suffire. En particulier, les derniers clients mails de MS*** etant tellement à pleurer, qu'il est parfois préférable de faires des newsletter html construites sur des images que ton parseur ne pourra jamais transformer decemment en newsletter texte.
Il *faut* pouvoir maitrîser le rendu sur la génération de la newsletter au format texte pour ceux qui ont demandé ce format.
C'était l'objet du mécanisme monpatron.html/mopatron_texte.html, qui a donc tout à voir avec le format de réception choisi par les internautes.

Il faudrait rétablir ce fonctionnement qui correspond aux besoin des utilisateurs. En revanche, je ne vois pas très bien à quel besoin pourrait correspondre ce que tu décris.

Cédric

5

-----Message d'origine-----
De : christophe le drean [mailto:christopheld@gmail.com]
Envoyé : dimanche 23 novembre 2008 18:56
[...]

c'est là où je ne suis pas certain de bien comprendre ce que tu
expliques par rapport au début de ton message : le format texte est
fait en fonction de quoi ? du patron version html (par exemple
portfolio.html) débarassé de son code html pour n'en garder que du
texte (il me semble que c'est ça qui se passe et ce que tu décris ici)
ou bien du patron en format texte (disons par exemple
portfolio_texte.html, et là, si je comprends bien ça colle avec ce que
tu expliques au début de ton message) ?

scénario :
- le message, quelque soit le patron, est traité comme un contenu HTML
- ce message est préparé par la trieuse et enregistré comme tel au format
HTML dans la table des courriers (spip_courriers)
- la méleuse en prépare la version texte à partir de cette version HTML si
l'abonné le souhaite

Difficile d'expliciter simplement, mais ...

Le nom du fichier patron (*_texte) n'a aucune influence sur le traitement du
format d'envoi de SPIP-Listes.

***

  Le format de réception est uniquement défini par le format de
réception choisi par l'abonné.

***

Si c'est la première solution, mais alors à quoi sert le patron
portfolio_texte qui disponible avec Spip-listes ?

C'est un exemple de patron. Rien de plus.

Allez! Courage!

Et merci pour le report.

6

Christian Paulus a écrit :

-----Message d'origine-----
De : christophe le drean [mailto:christopheld@gmail.com] Envoyé : dimanche 23 novembre 2008 18:56
[...]

c'est là où je ne suis pas certain de bien comprendre ce que tu
expliques par rapport au début de ton message : le format texte est
fait en fonction de quoi ? du patron version html (par exemple
portfolio.html) débarassé de son code html pour n'en garder que du
texte (il me semble que c'est ça qui se passe et ce que tu décris ici)
ou bien du patron en format texte (disons par exemple
portfolio_texte.html, et là, si je comprends bien ça colle avec ce que
tu expliques au début de ton message) ?

scénario :
- le message, quelque soit le patron, est traité comme un contenu HTML
- ce message est préparé par la trieuse et enregistré comme tel au format
HTML dans la table des courriers (spip_courriers)
- la méleuse en prépare la version texte à partir de cette version HTML si
l'abonné le souhaite

C'est bien là le problème.
Si la version html n'est constituée que d'images en table comme c'est malheureusement parfois obligatoire, la versin texte sera vide de texte !
Avant, le process de génération patron->html ou texte était réalisé au moment de la préparation par la trieuse, pour chaque destinataire.
Je comprends que tu aies pu vouloir optimiser, mais tu as perdu une fonctionnalité essentielle pour qui veut maitriser sa communication.

Cédric

7

Oui c'est ca, il s'agit d'un cas particulier :

si un patron est présent deux fois dont une avec le suffixe"_texte"

- monpatron.html
- monpatron_texte.html

alors c'est le patron monpatron_texte.html qui est utilisé pour calculer la version texte du message, c'est utile pour les cas ou l'on souhaite générer la version texte avec un patron (format texte en sortie) particulier.

Cela peut etre utile quand la version HTML d'un message est composé d' images ou des graphiques.

Mais c'est aussi plus lourd à gérer (deux patrons) et à traiter (deux calculs).

Donc le cas général, c'est une version texte calculée à partir de la version HTML du message par la fonction spip-listes_version_texte().

J'utilise ca toutes les semaines et ca marche assez bien ; même s'il faut avouer que sur ma version perso, je peux éditer la version texte et la version HTML avant chaque envoi : je crois que c'est finalement indispensable à l'usage.

BoOz

8

Je n'avais pas remarqué cette fonctionnalité à l'époque. Mille excuses.

Rajouté au TODO.

-----Message d'origine-----
De : Vincent Caron [mailto:booz.bloog@gmail.com] De la part de BoOz
Envoyé : lundi 24 novembre 2008 00:14
À : cedric.morin@yterium.com
Cc : Christian Paulus; spip-zone@rezo.net
Objet : Re: [SPIP-Listes 193] spip-listes : patron message en
format texte

Oui c'est ca, il s'agit d'un cas particulier :

si un patron est présent deux fois dont une avec le suffixe"_texte"

- monpatron.html
- monpatron_texte.html

alors c'est le patron monpatron_texte.html qui est utilisé
pour calculer
la version texte du message, c'est utile pour les cas ou l'on
souhaite
générer la version texte avec un patron (format texte en sortie)
particulier.

Cela peut etre utile quand la version HTML d'un message est
composé d'
images ou des graphiques.

Mais c'est aussi plus lourd à gérer (deux patrons) et à traiter (deux
calculs).

Donc le cas général, c'est une version texte calculée à partir de la
version HTML du message par la fonction spip-listes_version_texte().

J'utilise ca toutes les semaines et ca marche assez bien ; même s'il
faut avouer que sur ma version perso, je peux éditer la
version texte et
la version HTML avant chaque envoi : je crois que c'est finalement
indispensable à l'usage.

BoOz