Intéressant. Peux-tu donner un exemple simple de SqueleX ?
Bernard Martin-Rabaud
mel@ediweb.org
-----Message d'origine-----
Intéressant. Peux-tu donner un exemple simple de SqueleX ?
Je te fais ça vite fait, mais il faut que je vois ça de façon très
approfondie 
Je me suis inspiré du début du squelette d'Antoine :
http://rezo.net/~antoine/spip/sommaire.html
Oups, j’ai taper mon SqueleX vite fait sans éditeur à coloration syntaxique :
du coup je n’ai pas fermé certains tags …
Ou la la, il ne va pas être validé X(HT)ML !! 
Yves
SqueleX.html (1.36 KB)
Oui, c’est quand même plus clair que les boucles SPIP… Et c’est standard. Mais dit Antoine : quel intérêt ? C’est vrai que plus bavard que SPIP pur - et ça ne va pas faire plaisir aux concepteurs - dont la syntaxe fait un peu bricolage. Mais est-ce que les utilisateurs vont y venir ? C’est le problème…
Bernard Martin-Rabaud
mel@ediweb.org
oui, c'est quand même plus clair que les boucles SPIP... Et c'est standard.
Mais dit Antoine : quel intérêt ?
Tu as répondu, c'est d'être standard !
Mais aussi ça permet de simplifier le code php,
de rendre spip plus robuste (le parseur xslt vérifie les balises non
fermées, ...),
de se focaliser sur les fonctionnalités de spip (et non comment écrire,
débugguer puis maintenir un parseur SPIP).
Parmis les fonctionnalités à apporter, gérer simplement d'autres types
d'articles (disques, bibliographies, ...).
Aussi séparer l'interface utilisateur du code, spip le fait mais uniquement
pour la partie public, et il ne gère pas des thèmes de squelettes...
C'est vrai que plus bavard que SPIP pur
???
- et ça ne va pas faire plaisir aux concepteurs - dont la syntaxe fait un
peu bricolage.
Je n'aurai pas fait mieux, il y a deux ans je ne savais pas ce qu'était XSL
et je n'avais pas découvert SPIP (c'est spip qui m'a motivé pour travailler
avec XSL).
Mais est-ce que les utilisateurs vont y venir ? C'est le problème...
Si cette voie est utilisée pour les prochaines versions de SPIP, les
utilisateurs y passeront naturellement.
Ce qu'il faut c'est trouver "modèle" XML pour les SqueleX qui change le
moins possible les habitudes des utilisateurs, et qui ne bride pas les
possibilités de spip.
Je pense que c'est TRES facile de faire un nuke-like (i.e. système avec une
structure figée, pas de boucles dans les templates) avec du XSL en partant
de zéro.
A+
Yves
Salut
Yves Pratter a écrit :
>oui, c'est quand même plus clair que les boucles SPIP... Et c'est standard.
>Mais dit Antoine : quel intérêt ?
Tu as répondu, c'est d'être standard !
Mais aussi ça permet de simplifier le code php,
de rendre spip plus robuste (le parseur xslt vérifie les balises non
fermées, ...),
de se focaliser sur les fonctionnalités de spip (et non comment écrire,
débugguer puis maintenir un parseur SPIP).Parmis les fonctionnalités à apporter, gérer simplement d'autres types
d'articles (disques, bibliographies, ...).
Aussi séparer l'interface utilisateur du code, spip le fait mais uniquement
pour la partie public, et il ne gère pas des thèmes de squelettes...>C'est vrai que plus bavard que SPIP pur
???>- et ça ne va pas faire plaisir aux concepteurs - dont la syntaxe fait un
peu bricolage.
Je n'aurai pas fait mieux, il y a deux ans je ne savais pas ce qu'était XSL
et je n'avais pas découvert SPIP (c'est spip qui m'a motivé pour travailler
avec XSL).>Mais est-ce que les utilisateurs vont y venir ? C'est le problème...
Si cette voie est utilisée pour les prochaines versions de SPIP, les
utilisateurs y passeront naturellement.Ce qu'il faut c'est trouver "modèle" XML pour les SqueleX qui change le
moins possible les habitudes des utilisateurs, et qui ne bride pas les
possibilités de spip.
Je pense que c'est TRES facile de faire un nuke-like (i.e. système avec une
structure figée, pas de boucles dans les templates) avec du XSL en partant
de zéro.A+
Yves
Je comprends pas trop ce thread depuis quelque temps sur "mettre du Xml,
Xsl et etc..." dans Spip ?? Ou refaire Spip en Xml ??
Zope fait tout ça très bien (et même plus) ?? Pourquoi vouloir changer
ce qui fait la spécificité de Spip ?? Facile, performant, php plus connu
que Xml, ... ??
A+ Yann
yann wrote:
Je comprends pas trop ce thread depuis quelque temps sur "mettre du Xml,
Xsl et etc..." dans Spip ?? Ou refaire Spip en Xml ??
Ben, c'est que spip possède son système de balises perso à lui.
Il y en a simplement qui disent que c'aurait été pas bete de faire ses balises persos en XML. (le XML c'est justement fait pour pas que tout le monde invente son petit système de balisage dans son coin, mais justement pour unifier les méthodes et les rendre ainsi plus inter-oppérables).
Le plus dur c'est de trouver plus inter-oppérable avec quoi !!!
Facile, ...
Est-ce qu'on perdrait vraiment en facilité ?
> performant, ...
En performance ?
php plus connu que Xml, ...
L'XML est connu par pas mal de monde et ça va grandir.
stephane
Je comprends pas trop ce thread depuis quelque temps sur "mettre du Xml,
Xsl et etc..." dans Spip ?? Ou refaire Spip en Xml ??
Zope fait tout ça très bien (et même plus) ??
oui, mais spip est un outil visant à publier facilement de l'info, pas zope.
Pourquoi vouloir changer ce qui fait la spécificité de Spip ??
ça s'appelle "évolution", le "bébé" SPIP doit grandir
Facile, performant, php plus connu que Xml, ... ??
il ne s'agit pas de réécrire spip en XML.
ce n'est pas le match de boxe "PHP versus XML"
XML c'est une façon "propre" (en fait universelle) de stocker/décrire des
données.
PHP c'est un language de programmation.
Facile,
jette un oeil dans le parseur de spip (ou dans tout autre parseur écrit en
php, perl,...) et essaie de rajouter une toute petite fonction.
aarrg, vite de l'aspirine !
Performant
en quoi XML serait moins (ou plus) performant que PHP ?
le parseur XSLT est sans doute plus robuste et probablement plus rapide que
le parseur de spip écrit en php.
php plus connu que XML
demande à un développeur ASP, java, perl, delphi, ... si php est plus connu.
En tout cas, tous peuvent utiliser xml AVEC leur langage de prédilection.
Tu connais (X)HTML ? oui.
XHTML est écrit avec XML.
Tu connais le principe des balises <tag> ... </tag> ?
c'est bon, tu peux mettre le nez dans un source XML sans trop de problèmes
(PS: HTML 5.0 n'existe et n'existera jamais, la version suivante de HTML
4.01 s'appelle : XHTML 1.0)
Amicalement,
Yves
Intéressant. Peux-tu donner un exemple simple de SqueleX ?
Je te fais ça vite fait, mais il faut que je vois ça de façon très
approfondie
Ce qui serait pas mal, ce serait de faire des instructions conditionnelles
suivant la valeur d'un champ retourné par la boucle, ce qui oblige
actuellement à avoir recours au PHP. Genre <spip:cond var="titre"
value="français">...</spip:cond><spip:cond var="titre"
value="anglais">...</spip:cond>etc...
Sinon c'est bien, on peut intégrer du Javascript ou du PHP, XML ne râle pas.
Bernard Martin-Rabaud
mel@ediweb.org
suite à une fausse manipulation
de supression base /mauvaise réinstall de de spip (erreur de ma part)
j'ai une sauvegarde de la base et autres mais ... tout beugué
au moment de réinstal -> info administrateur = le doigt à glissé sur "enter" et résultat login inconu aucun accès ADMIN !!!
que faut-il que je supprime pour redémarer FTP ???
viiiiiite merci !
MERCI !!!
TiTeuf a écrit:
suite à une fausse manipulation
de supression base /mauvaise réinstall de de spip (erreur de ma part)j'ai une sauvegarde de la base et autres mais ... tout beugué
au moment de réinstal -> info administrateur = le doigt à glissé sur "enter" et résultat login inconu aucun accès ADMIN !!!que faut-il que je supprime pour redémarer FTP ???
suite ... accès restauré
mais ... restauration du dump.xml > accès rufusé !!!
mais pourquoi !!!
Bonjour,
Performant
en quoi XML serait moins (ou plus) performant que PHP ?
le parseur XSLT est sans doute plus robuste et probablement plus
rapide que le parseur de spip écrit en php.
Certes, mais l'extension XSLT de PHP est plutôt rarement installée
chez les hébergeurs, à ma connaissance, donc cela ne convient pas au
principe général qui veut que SPIP puisse être utilisé par tout le
monde.
Sinon, on abandonne la compatibilité PHP3, on se moque des configs
spécifiques des différents hébergeurs pour le mail, on utilise
carrément la syntaxe DocBook XML, ...
Donc non, pas de XSLT, sauf si on ajoute une lib qui sait le faire en
PHP quand l'extension XSLT n'est pas dispo.
-Nicolas
Certes, mais l'extension XSLT de PHP est plutôt rarement installée
chez les hébergeurs, à ma connaissance, donc cela ne convient pas au
principe général qui veut que SPIP puisse être utilisé par tout le
monde.
Je suis bien d'accord avec toi.
Je parle d'une version 2.0 de spip, qui ne verra pas le jour avant des mois.
On a déjà évoqué sur la liste la date de passage définitif en PHP4 :
dans un an environ.
ça ce fera de toute façon, en fait tout naturellement, car petit à petit les
hébergeurs ne vont plus s'emm.. avec PHP3, PHP5 sera probablement sorti
entre temps ...
Sinon, on abandonne la compatibilité PHP3, on se moque des configs
spécifiques des différents hébergeurs pour le mail, on utilise
carrément la syntaxe DocBook XML, ...
Donc non, pas de XSLT, sauf si on ajoute une lib qui sait le faire en
PHP quand l'extension XSLT n'est pas dispo.
Pourquoi tant de haine
il ne s'agit pas de se moquer de qui que ce soit.
Essaie de faire preuve d'ouverture :
qu'est-ce qui empêche de développer puis sortir une version 2 qui soit XML,
bleue, atomique ... et qui fonctionne uniquement en PHP4 ?
Et que en parallèle, les utilisateurs d'hébergeurs PHP3 continuent à
utiliser SPIP1.4 voir SPIP1.3 ?
Le jour où leur hébergeur ne supporte plus PHP3, il seront bien obligés
d'évoluer, non ?
Personne et surtout pas moi ne parle de révolutionner le monde, d'ignorer
les utilisateurs de spip qui ont fait son succès, j'oublie ses créateurs
....
Si SPIP 2.0 garde le même concept que SPIP1.4, peut importer sans problèmes
les données et permet de mettre à jour un squelette en SqueleX sans trop de
sueur,
OU EST LE PROBLEME ?!
Merci de votre écoute.
Yves
PS: spip-dev est bien une liste pour "discuter" des évolutions de SPIP ?
il ne s'agit pas de se moquer de qui que ce soit.
Je ne me suis moqué de personne !
Essaie de faire preuve d'ouverture :
Hum hum ... il me semble que c'est le cas, désolé si j'ai été cassant.
qu'est-ce qui empêche de développer puis sortir une version 2 qui
soit XML, bleue, atomique ... et qui fonctionne uniquement en PHP4 ?
Et que en parallèle, les utilisateurs d'hébergeurs PHP3 continuent à
utiliser SPIP1.4 voir SPIP1.3 ?
Rien, je l'ai souligné déjà maintes fois.
PS: spip-dev est bien une liste pour "discuter" des évolutions de
SPIP ?
Oui.
-Nicolas