Bonjour,
Je teste Spip 1.2beta9 chez un FAI et celui-ci m'a signalé un nom de fichier
dans le cache comme étant bizarre :
%2F%7Elrathle%2Farticle.php3%3Fid_article%3D2%26id_article%3D2%26nom_email%3Dlolo%26ad_email%3Dlrathle%2540kde-france.org%26nom_
Ça correspond à un article avec pétition.
Est-ce si bizarre ?
Salut ...
Je vais me lancer dans le developpement de modules pour de l'export de
contenu SPIP vers wap et pda .....
un conseil ? un tuyau ?
Christophe
Le système des templates permet, à peu pres, de créer des fichier
WML au lieu de fichier HTML. Parmis les difficultés, je vois tout
de suite les suivantes (liste non exhaustive):
- les fichiers produits par spip ne sont pas compatible XML, mais
seulement HTML.
- Les format d'images sont forcément: gif, jpeg ou png. À vérifier
si ces formats sont suffisants pour le WAP.
- La mise en forme d'un texte devra sans doute être re-écris.
Je ne crois pas que le WAP interesse beaucoup de monde parmi les
utilisateurs de SPIP. En revanche, avoir un SPIP compatible XML
ça peut être utile à d'avantage de sites. Si la mise en forme du
texte en WML est assimilé à une mise en forme pour une langue
particulière, il y a peut être un moyen de travailler en
parallèle avec les développeurs officiels de SPIP lorsqu'ils en
viendront à traiter l'aspect multilingue.
Bon courage
Michaël P
Bonjour,
Le système des templates permet, à peu pres, de créer des fichier
WML au lieu de fichier HTML.
Sans problème tant qu'on n'utilise pas les filtres de mise en forme,
les URL, les tableaux, ... 
Parmis les difficultés, je vois tout de suite les suivantes (liste
non exhaustive):
- les fichiers produits par spip ne sont pas compatible XML, mais
seulement HTML.
Uniquement pour ce qui est des données, les templates peuvent très
bien être en XML, comme c'est le cas pour le backend, et donc en WML.
- Les format d'images sont forcément: gif, jpeg ou png. À vérifier
si ces formats sont suffisants pour le WAP.
Pas avec la version actuelle, qui n'accepte que les images WBMP.
Je ne crois pas que le WAP interesse beaucoup de monde parmi les
utilisateurs de SPIP.
Pourquoi donc ?
En revanche, avoir un SPIP compatible XML ça peut être utile à
d'avantage de sites.
Réserver la mise en forme aux templates et donc pouvoir gérer
n'importe quel format texte devrait être une possibilité native de
SPIP. Ainsi, on pourrait générer du XML auquel on puisse appliquer du
XSL pour générer du XHTML, du WML, d'autres XML ...
Bien sûr, ce n'est qu'un voeux, mais pouvoir déjà définir sa mise en
page avec des feuilles de style serait un plus. Trop de mises en forme
HTML sont effectuées par SPIP actuellement. Je pense notamment aux
tableaux pour lesquels il faut rentrer dans le code pour changer les
couleurs de fond et de bordures ...
Je veux bien travailler sur un passage en XHTML + CSS si ça vous
intéresse ...
Si la mise en forme du texte en WML est assimilé à une mise en forme
pour une langue particulière
Non, cela n'a à mon avis rien à voir.
-Nicolas
Salut Michael,
"Michaël Parienti" wrote:
Le système des templates permet, à peu pres, de créer des fichier
WML au lieu de fichier HTML. Parmis les difficultés, je vois tout
de suite les suivantes (liste non exhaustive):- les fichiers produits par spip ne sont pas compatible XML, mais
seulement HTML.
Heu, comment ça ? Tu veux parler de la correction typographique
et des raccourcis de mise en page ?
a+
Antoine.
- les fichiers produits par spip ne sont pas compatible XML, mais
seulement HTML.
C'est la fonction propre() qu'il faudra remplacer. Vous pouvez recopier
l'actuelle propre() dans mes_fonctions.php3 sous le nom propre_wap() et la
rendre compatible avec le format désiré. Ensuite dans les squelette vous
appelez (#TEXTE*|propre_wap) ou lieu de #TEXTE
Autre solution, s'il s'agit seulement de corriger quelques petites choses
dans ce que produit propre(), faire un fonction supplémentaire nettoie_wap()
et appeler (#TEXTE|nettoie_wap) ; ainsi d'éventuelles améliorations futures
de propre() seront prises en compte directement.
Et si la fonction créée est assez fiable et générique, on pourra l'intégrer
à SPIP.
- La mise en forme d'un texte devra sans doute être re-écris.
Pas compris. Un texte au format "SPIP" (c-à-d sans trop de HTML et avec les
balises {italiques} {{gras}} etc. devrait être traduisible sans difficultés
dans n'importe quel format. Pierre Lazuly a travaillé sur un format LaTeX,
et il est aussi envisageable de faire un format... image ! De plus le WML
n'est pas hyper-éloigné du HTML...
-- Fil
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
Bien sûr, ce n'est qu'un voeux, mais pouvoir déjà définir sa mise en
page avec des feuilles de style serait un plus. Trop de mises en forme
HTML sont effectuées par SPIP actuellement. Je pense notamment aux
tableaux pour lesquels il faut rentrer dans le code pour changer les
couleurs de fond et de bordures ...
Oui, c'est une sorte de bug, qu'on devrait pouvoir corriger en y
réfléchissant bien. Déjà, pour le diplo, j'utilise un autre format de
tableaux, avec des couleurs alternées (jaune clair/jaune moins clair/jaune
clair/...) ; pour cela j'intercepte le #TEXTE avant qu'il n'ait été traité
par propre(), puis je l'envoie dans une fonction table_alternee() qui
traite les tableaux à ma manière, puis dans propre :
(#TEXTE*|table_alternee|propre)
La fonction table_alternee() est si crado que je n'ose pas la copier
ci-dessous (m'enfin, elle marche et je la copie pour vous donner envie d'en
faire une plus jolie) :
function table_alternee($texte) {
$letexte = ereg_replace("\r","\n",$texte);
$letexte = ereg_replace ("DEBUT_CHIFFRES_CLES\n+\|","\n\n\n||",$letexte);
$letexte = ereg_replace ("\|\n+FIN_CHIFFRES_CLES","||\n\n\n",$letexte);
if (is_integer(strpos($letexte, "\n\n\n||"))) {
$letexte = ereg_replace("\n\n\n\|\|",
"<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH=200><TR BACKGROUND=\"/img/rayures-gris.gif\" BGCOLOR=\"#F0F0F0\"><TD colspan=2><IMG SRC=\"/img/triangle.gif\" WIDTH=8 HEIGHT=7 alt=\">\">
Chiffres clés|\n|",
$letexte);
$letexte = ereg_replace("\|\|\n\n\n","|\n<TR><TD colspan=2 align=right><A href=\"/cles/sources/\"><font size=2><I>Sources.</I></font></A></TD></TR>\n</TABLE><P>",$letexte);
$letexte = ereg_replace("\n\|","\n<TR bgcolor='SPIP_COLOR_COLOR' valign=top><TD><font size=2>",$letexte);
$letexte = ereg_replace("\|\n","</font></TD></TR>\n",$letexte);
$letexte = ereg_replace("\|","</font></TD><TD><font size=2>",$letexte);
$ztexte = split("SPIP_COLOR_COLOR",$letexte);
// initialise
list(,$letexte) = each($ztexte);
// boucle
while(list(,$toto) = each ($ztexte)){
if ($color != 'ffffee')
$color = 'ffffee';
else
$color = 'ffffdd';
$letexte .= $color.$toto;
}
}
return $letexte;
}
-- Fil
Hello,
Un texte au format "SPIP" (c-à-d sans trop de HTML et avec les
balises {italiques} {{gras}} etc. devrait être traduisible sans
difficultés dans n'importe quel format.
Y compris en XML, en effet.
Avec du XML (format légèrement plus utiliser que le langage SPIP dans
le monde ), on peut générer à peu près tous types de contenus plus
ou moins standardisés ...
C'est donc une possibilité que SPIP se doit d'avoir en natif.
Pierre Lazuly a travaillé sur un format LaTeX
Ouh la la, et c'est pas diffusé largement, ça ??? 
et il est aussi envisageable de faire un format... image !
Euh ... faut pas abuser non plus, le PDF devrait suffire ...
De plus le WML n'est pas hyper-éloigné du HTML...
Si on appelle HTML le XHTML, oui, mais le HTML "pondu" actuellement
par SPIP et proposé dans les squelettes par défaut, bof ...
WML, c'est du pur XML, et la gestion de navigation et de formulaire
n'est pas la même qu'en HTML.
Cela va évoluer avec WAP 2.0, mais avant que les utilisateurs finaux
aient des terminaux capables de l'exploiter, on a le temps ...
-Nicolas
Hello (again),
pouvoir déjà définir sa mise en page avec des feuilles de style
serait un plusOui, c'est une sorte de bug, qu'on devrait pouvoir corriger en y
réfléchissant bien.
A mon avis, c'est très simple de définir une feuille de style CCS1 par
défaut modifiable par les utilisateurs tout comme les squelettes.
Que SPIP génère par exemple <table class="spip_table"> pour gérer
toute la mise en page des tableaux via la feuille de style.
Au final, le moteur de SPIP ne doit générer que du contenu, pas de
mise en forme. Donc plus de tags <FONT..> notamment ...
-Nicolas
Je veux parler des <img > qui devraient être <img />
des <br> qui devraient être <br/>
des <p> qui devraient être fermés...
(à vérifier, spip utilise-t-il des balise <p>?)
J'ai déjà eu des bugs avec un fichier backend qui contenait des
images «tirets» et des sauts de lignes... Je voulais le corriger,
puis j'ai oublié de le faire, et de le signaler sur la mailing
liste. Mea Culpa.
Il me semble que le passage en XHTML a déjà été abordé, puis
abandonné.
Michaël P.
Uniquement si les mainteneurs sont eux aussi d'accord, je ne voudrais
pas faire un fork de SPIP ...Si c'est bien fait, il n'y a pas de raison qu'on soit contre !
J'avais pourtant été reçu vertement il y a quelque temps quand j'avais
parlé de XHTML ... 
Il ne faut pas que ça ait pour conséquence une baisse de la qualité
(technique, cela va de soi, mais également graphique) de ce qui
existe aujourd'hui, voilà tout.
Ca me semble clair ...
Ah oui! : du code (relativement) propre !
Euh ... c'est évident, non ?
On passe cette discussion sur spip-dev ?
Elle y était, Maurice a jugé bon de montrer aux utilisateurs que je me
proposais pour une évolution, je suppose ...
-Nicolas
ben je pensais pas créer une telle animation sur SPIP-DEV
pour l'histoire du XHTML je crois que ca fait peur aux utilisateurs basiques
...
beaucoup sont débutant en HTML ... et vont s'effrayer a l'annonce d'une
version en XHML .. (c'est une version "rose" du Html ?) lol
CM
------------D2EEE5CC53629
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
On passe cette discussion sur spip-dev ?
Bon, voici un premier jet basé sur la dernière version en install
auto.
Pour la liste des propriétés CSS1, voir ici :
http://www.w3.org/TR/REC-CSS1-961217.html#css1-properties
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
Bon, voici un premier jet basé sur la dernière version en install
auto.
eh bien ça a l'air pas mal. Est-ce qu'on peut imaginer intégrer, une ligne
sur deux, un <TR type pair> puis <TR type impair>, de manière à faire des
tableaux dont les lignes sont de couleurs alternées en modifiant juste des
feuilles de style ? Ce serait vachement bath', comme on disait dans les
années 70.
a +
-- Fil
Hello,
Nicolas Hoizey wrote:
>> On passe cette discussion sur spip-dev ?
Bon, voici un premier jet basé sur la dernière version en install
auto.
C'est 'achement bien. Par contre, fais gaffe, la version en
install auto est la dernière version officielle (1.0.6), il
vaut mieux prendre la dernière beta ; heureusement ça ne doit
pas changer grand'chose pour inc_texte.php3.
a+
Antoine.
Hello,
Bon, voici un premier jet basé sur la dernière version en install
auto.eh bien ça a l'air pas mal.
Ouf ...
Est-ce qu'on peut imaginer intégrer, une ligne sur deux, un <TR type
> puis <TR type impair>, de manière à faire des tableaux dont
les lignes sont de couleurs alternées en modifiant juste des
feuilles de style ? Ce serait vachement bath', comme on disait dans
les années 70.
J'ai essayé de faire ça via des instructions CSS2, mais je ne suis pas
encore bien au point malheureusement. Pour le faire en PHP, c'est un
peu plus chaud puisqu'on ne différencie pas les lignes traitées, on
fait tout d'un coup. Traiter en amont comme tu le fait sur le Diplo
doit être plus couteux, mais on peut tenter le coup.
Je vais regarder ton code, et eventuellement l'intégrer directement à
'inc_texte.php3', mais as-tu un exemple de ce que ça donne sur le
Diplo ?
Il faudrait aussi du même coup pouvoir traiter différemment la
première ligne, non ?
-Nicolas
Bon, voici un premier jet basé sur la dernière version en install
auto.C'est 'achement bien. Par contre, fais gaffe, la version en install
auto est la dernière version officielle (1.0.6)
Euh ... à priori, c'est même une 1.0.5 que j'ai, en tout cas c'est ce
qui était marqué sur Uzine ...
il vaut mieux prendre la dernière beta
En effet, mais j'en ai profité pour montrer à un pote la magie de
l'install auto ...
heureusement ça ne doit pas changer grand'chose pour inc_texte.php3.
Je vais regarder.
-Nicolas
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
J'ai essayé de faire ça via des instructions CSS2, mais je ne suis pas
encore bien au point malheureusement. Pour le faire en PHP, c'est un
peu plus chaud puisqu'on ne différencie pas les lignes traitées, on
fait tout d'un coup. Traiter en amont comme tu le fait sur le Diplo
doit être plus couteux, mais on peut tenter le coup.
Je pense qu'il faut modifier propre() en profondeur sur ce coup-là : repérer
les tableaux un par un de manière fine (avec des strpos()), puis envoyer les
tableaux un par un dans une fonction tableaux($tableau) qui transforme en
html correct tout ce qu'on lui envoit qui commence par | et finit par |.
Je vais regarder ton code, et eventuellement l'intégrer directement à
'inc_texte.php3', mais as-tu un exemple de ce que ça donne sur le
Diplo ?
http://www.monde-diplomatique.fr/index/pays/algerie
Il faudrait aussi du même coup pouvoir traiter différemment la
première ligne, non ?
oui ! structure comme ça tes feuilles de style :
spip_tr_debut
spip_tr_pair
spip_tr_impair
spip_tr_pair
spip_tr_impair
...
PS: fais la même chose sur les intertitres : spip_inter
-- Fil
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
> heureusement ça ne doit pas changer grand'chose pour inc_texte.php3.
Il y avait une accélération genre *100 sur une instruction
-- Fil
Je pense qu'il faut modifier propre() en profondeur sur ce coup-là
Je suis bien d'accord, je vais bosser dans ce sens.
Euh ... la différence est tellement faible que même en mettant le
contraste au maximum, on ne la voit que si on sait qu'elle existe,
avec un écran de portable ... 
structure comme ça tes feuilles de style :
spip_tr_debut
spip_tr_pair
spip_tr_impair
spip_tr_pair
spip_tr_impair
...
non, plutôt row_first, row_odd et row_even à mon avis, et en gérant la
cascade avec un table.spip on s'en sortira très bien.
PS: fais la même chose sur les intertitres : spip_inter
Ouh la la, je fini les tableaux, et après on verra, hein ...
-Nicolas