[spip-dev] [xhtml]

Dev
1

Bonjour,
Stephane va bosser sur l'xhtmlisation de spip.
le site spip-contrib va passer sur la version spip1.7.a7

Puis chaque changement de stephane (ou d'autres s'ils veulent participer) sur le
"noyau" spip sera integre regulierement sur le site de spip-contrib pour avoir un
exemple concret et etre sur que l'on ne casse rien .

tous les changements seront bien commentes, pour etre reintegre plus facilement.

A+
Benoit

P.S : si des discussions se passent sur la liste spip-dev a ce sujet, merci de garder
le [xhtml]

2

Salut,

Bonjour,
Stephane va bosser sur l'xhtmlisation de spip.

Que veux-tu dire par là ?
L'espace public, les squelettes, l'espace privé ?

a+

Antoine.

3

Que veux-tu dire par là ?
L'espace public, les squelettes, l'espace privé ?

L'espace publique avec les squelettes de spip-contrib comme test de validation .

Je pense que faire l'espace privee en meme temps est un peu trop non ?

Benoit

4

Ben. wrote:

Stephane va bosser sur l'xhtmlisation de spip.

je comprend pas, qu'est-ce que SPIP a à voir dans cette affaire ?
SPIP ne faire que faire des boucle sur du code ecrit dans des squelettes.
Si le code des squelettes est correcte, le code produit apres SPIP le sera non ?
bon d'accord SPIP génère 2 ou 3 petites choses mais globalement, tout
est à la charge du développeur de squelettes non ?

5

[j'ai encore tenté de poster via le ng gmane, j'ai pas dû tout piger... je reposte via mail]

Tu as tout à fait raison, les squelettes n'ont que peu à voir à l'affaire. C'est pourquoi ce que je vais gérer en test sera monté avec les squelettes par défaut de spip, et Ben quant à lui fera écho de ems modifs sur spip-contrib.

Ce qui pêche, tu l'as bien compris, c'est la génération du conteu (les # divers). C'est là-dessus aussi que je vais travailler.

6

Salut
une parse error sur spip contrib

http://www.uzine.net/spip_contrib/ecrire/message.php3?id_message=153

a+
phil

7

s t e f wrote:

Ce qui pêche, tu l'as bien compris, c'est la génération du conteu (les # divers). C'est là-dessus aussi que je vais travailler.

ok, tres bien, c'est assez localisé comme modifs ; et puis ca n'a pas besoin de bcp d'explications.
dans ce cas, il serait plutot intéressant d'acceder directement au serveur CVS, de s'y mettre a 4 ou 5
de localiser tout ce qui doit etre retouché, et d'y aller a fond (2j de trvail a tout cassé) et mettre en
commentaire de commit CVS un truc du genre XHML.

a négocier avec le staff des core-dev.

8

@ Marc Quinton <quinton@free.fr> :

dans ce cas, il serait plutot intéressant d'acceder directement au
serveur CVS, de s'y mettre a 4 ou 5
de localiser tout ce qui doit etre retouché, et d'y aller a fond (2j de
trvail a tout cassé) et mettre en
commentaire de commit CVS un truc du genre XHML.

a négocier avec le staff des core-dev.

Le plus simple c'est de nous envoyer un gros diff contenant toutes vos
modifications (par rapport à la version CVS, évidemment !).

Méthode :

1) charger la cvs
    cvs checkout ...
    faire vos modifications, débugguer, tester...

2) regarder vos modifications
    cvs diff -pu > fichier.diff

3) nous les envoyer
    mail spip-dev@rezo.net < fichier.diff
    (ou s'il est trop gros, envoyer l'URL du fichier).

Si entre temps nous faisons des modifs dans le CVS, un petit 'cvs update'
vous resynchronise.

-- Fil