[spip-dev] Pense-bête pour les boucles

Ce lundi 9 septembre, Stephane le solliec a écrit:

>Mais dit Antoine : quel intérêt ?

L'interet, c'est que mon éditeur texte (HomeSite pour ne pas le nommer
mais pour les autres ça doit être pareil) comprends très bien la syntaxe
XML.

Si on arrive à une DTD qui définisse toutes les balises SPIP comme étant
de l'XML, alors je peux donner la DTD à mon editeur qui va :
   - appliquer une jolie coloration syntaxique à mes balises spip
   - me les fermer tout seul ou en tester la fermeture
   - me proposer une petite fenetre avec la liste de tous les arguments
possibles dans chaque balise.

Bref, rendre la vie beaucoup plus simple lors de l'edition de skeleXes
parce que beaucoup d'editeurs sont déjà orienté XML.

:wink:

Mais je suis suprise. Qu'est-ce que je ne comprends pas?
Vous voulez demander à des développeurs qui ont fait un programme
(pour présenter des pages stockées dans une base de donnée qu'ils
ont conçue et en plus avec tous les outils pour stocker ces pages
dans la base de donnée) de récrire tout leur code pour qu'il ne lise
non plus des squelettes en html mais des skelettes en xml?
Ai-je compris?

Si tel est le cas, il faut s'adresser à d'autre développeurs. Ou, mieux
encore, mettre en route ce que vous pensez qui serait bien et le proposer
à la communauté. Mais il faut bien savoir que ce sera toujours un
fork de ce qui existe. Car celles et ceux qui ont investi, et qui ont un
site qui tourne, elleils ne feront pas le changement de ce qui fonctionne
pour satisfaire celles et ceux qui souhaitent autre chose.

Spip a une stratégie. Il y en a beaucoup d'autres. Pourquoi vouloir qu'une
stratégie en devienne une autre? Pourquoi vouloir que tout le monde
change ce qui marche.

Il est très hautement probable que XML va devenir un standard.
Tout bouge tellement vite dans ce monde...

Donc qu'un autre SPIP (XSPIP?) voie le jour. Et quelques courageux feront
la moulinette nécessaire pour transformer de SPIP en XSPIP.
Mais ne demandons pas à ceux qui ont fait SPIP de le jeter pour XSPIP.
Laissons-les maintenir leur produit, pour la communauté qui l'utilise,
et avec l'esprit positif qu'ils ont.

Après, s'il existait un autre Système de Gestion de Contenu comme SPIP,
basé sur un autre langage de gabarits (skelettes) là aussi XML, alors il
serait possible de créer une feuille XSL qui transformerait
automatiquement les gabarits d'un système dans les gabarits d'un autre.
(bon, ok, cette application est sans doute totallement marginale, mais
c'est juste pour illustrer l'interet de l'XML en général).

Donc, si vous voulez construire une équipe XSPIP, bienvenue.
Et si je n'ai rien compris, merci de me le dire.
Mais je vois mal maintenir un SPIP qui marche avec les squelettes et
avec les skelettes. A moins d'un code spaghetti qui ne peut qu'être
truffé de bugs.

Les langages, c'est un débat à l'infini.

Connaissez-vous les CFM en perl?

"Two Open Source content management packages reviewed (NewsForge)"
  Two Open Source content management packages reviewed (NewsForge) [LWN.net]

Ils naissent chaque jour...

        Anne

P.S. Je suis aussi convaincue que XML a un bel avenir. Il y aura des
bases de données en XML en direct (je crois que cela existe, mais
non libre).

P.P.S. Il me semble (mais je ne suis encore qu'au début) que les
squelettes avec des stylesheet (CSS2) de bonne qualité peuvent faire
des squelettes très propres.

Salut

Anne Possoz a écrit :

Mais je suis suprise. Qu'est-ce que je ne comprends pas?
Vous voulez demander à des développeurs qui ont fait un programme
(pour présenter des pages stockées dans une base de donnée qu'ils
ont conçue et en plus avec tous les outils pour stocker ces pages
dans la base de donnée) de récrire tout leur code pour qu'il ne lise
non plus des squelettes en html mais des skelettes en xml?
Ai-je compris?

[zap]
Je suis entièrement d'accord avec toi Anne et c'était les ens de mon
intervention précédente sur ce sujet :wink:
Tu l'a mieux exprimé que moi.

A+ Yann

Vous voulez demander à des développeurs qui ont fait un ...

On demande rien, on discute.

On est tous d'accord sur le fait que spip est une merveille, je suis personnellement complètement admiratif devant la qualité du back-office, ainsi que de la doc.

J'ai développé l'année derniere 2 CMS pour des clients, si c'était à refaire maintenant, je prendrai spip illico, car c'est infiniement mieux que le résultat auquel je suis arrivé.

Une chose me semble évidente maintenant : Spip va être utilisé. On peut meme etre certain que le raz de marrée sera massif, tellement spip 1.4 est enthousiasmant.

Maintenant, avec Yves, on est au moins 2 à penser qu'il aurait été chouette que le langage de balises ait été de l'XML.

Donc qu'un autre SPIP (XSPIP?) voie le jour. Et quelques courageux feront
la moulinette nécessaire pour transformer de SPIP en XSPIP.

Pis le problème, c'est que les vieux skelettes marcheront plus, ce qui n'est pas marrant non plus, et comme ils ne sont pas en XML, ils sont moins facilement transformables.

Dans ce monde où tout bouge si vite comme tu dis, créer un langage de balisage sur l'XML, c'est lui donner toutes les chances de pouvoir bouger facilement.

Connaissez-vous les CFM en perl?

"Two Open Source content management packages reviewed (NewsForge)"
  Two Open Source content management packages reviewed (NewsForge) [LWN.net]

Ils naissent chaque jour...

oui, et si on développait un langage de skeleXes en XML, les skeleXes d'un système pourraient "presque" être utilisables par un autre.

bon allez, j'arrette de polluer la lidie, si jamais vous êtes pas convaincus, alors je dois trop vous casser les pieds.

        Anne

P.S. Je suis aussi convaincue que XML a un bel avenir...

on est bien d'accord, raz-le-bol de voir de pauvres secrétaires s'échiner sur DreamWeaver pour mettre un site à jour, vive SPIP !!!

:slight_smile:

P.P.S. Il me semble (mais je ne suis encore qu'au début) que les
squelettes avec des stylesheet (CSS2) de bonne qualité peuvent faire
des squelettes très propres.

Très propre oui, mais ... pas valides, ... à cause de propre justement.
Mais c'est un autre débat :wink:

stephane le casse pied

Vous voulez demander à des développeurs qui ont fait un programme
[...] de récrire tout leur code pour qu'il ne lise
non plus des squelettes en html mais des skelettes en xml?
Ai-je compris?

Stéphane à répondu je crois, et j'ai répondu au mel de Nicolas.
Tant pis j'effonce le clou :

Non,

[...]Car celles et ceux qui ont investi, et qui ont un
site qui tourne, elleils ne feront pas le changement de ce qui fonctionne
pour satisfaire celles et ceux qui souhaitent autre chose.

Qui te parle de tout changer ?

Spip a une stratégie. [...] Pourquoi vouloir que tout le monde
change ce qui marche.

idem.

Mais ne demandons pas à ceux qui ont fait SPIP de le jeter pour XSPIP.

je ne crie pas "le roi est mort, vive le roi !"

Je ne crache pas sur le travail d'Antoine, Aranud et de Phil.
Je ne souhaite surtout pas jeter quoi que ce soit.

Simplement, j'indique des pistes pour répondre à des problèmes que des
utilisateurs de spip se posent (dont moi).

Avec mon expérience de développeur, je me rend compte qu'un parseur "fait
main" arrive à ses limites :
- c'est peu robuste,
- difficilement maintenable
- encore plus difficilement extensible si tu ne l'as pas écrit toi-même.

Ainsi comment rajouter simplement un boucle "calendrier" ou traiter d'autres
types d'articles pour un site parlant de techno :

Pour un site dédié à la musique, il serait en effet
préférable de parler de "morceau", "date de sortie", "label" et
"groupe" que d'"intertitre", "sur-titre", "date de publication
antérieure" ou autre.

Je ne parle pas non plus de l'internationalisation de l'interface,
d'articles multilangues et d'accessibilité...

Spip doit naturellement évolué. Je ne parle QUE d'évolution.
J'essaie de faire des propositions constructives, et ne pas me contenter de
yaka (demander à Phil de développer ça ...).

D'ailleurs qu'en pensent-ils "nos" mousquetaires ?

Laissons-les maintenir leur produit, pour la communauté qui l'utilise,
et avec l'esprit positif qu'ils ont.

Pourquoi tant de haine ? (bis repetita :slight_smile: )

D'ailleurs je fais aussi partit de la communauté, non ?
La liste spip-dev est là pour proposer, partager discuter du futur de spip.
Non ?

Donc, si vous voulez construire une équipe XSPIP, bienvenue.

Merci :-))

C'est à peu près ça, me je ne souhaite pas réinventé la roue.
(tout comme c'est dommage de le faire pour le parseur).

A moins d'un code spaghetti qui ne peut qu'être truffé de bugs.

c'est surtout ce que je veux éviter

Connaissez-vous les CFM en perl?

je ne connaissais pas, mais ce n'est pas exactement ce dont il s'agit pour
spip.
CFM c'est, si j'ai bien compris, des données XML certe, mais pour
stocker/échanger des types de données "informatiques" (tableaux, ...)

Dans spip, il s'agit de stocker des articles (au sens large).

P.P.S. Il me semble (mais je ne suis encore qu'au début) que les
squelettes avec des stylesheet (CSS2) de bonne qualité peuvent faire
des squelettes très propres.

Je ne vois pour le moment qu'un Squelette "X(HT)MLisé" avec toujours des
CSS2.
Bien que IE, Opéra et Netscape supportent XSL.

Il existe les XSL-FO (la version XSL de CSS2 je crois).
A voir ...

Allez a plus.

Amicalement,
Yves

PS: peut-être à un de ces jours lors d'une recontre Spip à Genève, pourquoi
pas ?
(j'habite Annecy, et "je ne suis pas Parisienne, ça me gêne, ça me gêne
...")