Je sais que je vous en ai déjà parlée, et que peut être ceci n'interesse pas tous les developpeurs de spip, mais j'aimerai avoir l'avis de personnes éclairées ayant l'habitude du develloppement SPIP sur cette contrib:
Je l'ai à l'origine développée dans le but d'une simplification de certaines combinaisons de filtres que j'avai à utiliser. Mais Noe-de-Naama m'a donné pas mal d'idées et a pensé à plusieurs choses qui pourraient vous interesser.
J'ai enfin fini de mettre à jour la contribution.
En résumé, on peut déclarer dans des fichiers XML assez simples de nouvelles balises spip, sans avoir à coder une seule ligne de php.
Ces fichiers xml sont compilés en fonctions balise_...
Le but est de mettre à disposition de tous la possibilité de déclarer des alias (ou macro, meme si on ne fait pas de vraie programmation) vers des balises ou ensemble de balises SPIP.
A première vue, cela sert juste à se simplifier un tout petit peu la vie en tappant moins de chose. Mais plusieurs fonctionalités vont permettre une utilisation plus avancée (je l'espere).
A terme, des blocs personalisables (par le passage de paramètre aux balises) de code spip, html, rss, latex pourront être fournis pour être accessible au gens qui n'y connaissent rien à toutes ces technologies.
Pour ceux qui les connaissent, cela permettra une meilleure réutilisation et modularisation des squelettes. Enfin, je pense.
Je ne sais pas si c'est clair tout ce que je dis
Enfin, la contribution n'attend que vos commentaires et avis.
Le but est de mettre à disposition de tous la possibilité de déclarer
des alias (ou macro, meme si on ne fait pas de vraie programmation) vers
des balises ou ensemble de balises SPIP.
Enfin, la contribution n'attend que vos commentaires et avis.
Si tu insistes...
XML pour un langage de macros ou même de fonctions, c'est pas un peu verbeux ?
On risque de taper verfication au lieu de verification par exemple...
Sinon je pense toujours que plutôt que de continuer à compliquer le langage,
ça serait plus simple de mettre un échappement pour passer en PHP évalué avant la compilation.
(désolé si vous en avez déjà parlé mille fois sur la liste mais j'étais pas là.)
XML pour un langage de macros ou même de fonctions, c'est pas un peu
verbeux ? On risque de taper verfication au lieu de verification
par exemple...
c'est juste plus simple pour moi à parser
à la base, ct pour simplifier l'ecriture à la fin, pas au début...
Sinon je pense toujours que plutôt que de continuer à compliquer le
langage, ça serait plus simple de mettre un échappement pour passer
en PHP évalué avant la compilation. (désolé si vous en avez déjà
parlé mille fois sur la liste mais j'étais pas là.)
C'est fait pour eviter au gens qui y connaissent rien en php à tapper du php pour avoir un alias.
C'est donc pas vraiment pour faire la même chose que ce que toi tu proposes (qui n'est pas une mauvaise idée non plus)
Là tu fais une identification un peu rapide entre le créateur (humain) et son oeuvre (le code).
Pour tes neurones, c'est plus simple de parser
#A = #B
que
<xml><a>[!CDATA #B]</a></xml>
à la base, ct pour simplifier l'ecriture à la fin, pas au début...
Simplifier aux deux bouts c'est encore mieux.
C'est fait pour eviter au gens qui y connaissent rien en php à tapper du
php pour avoir un alias.
On arrive au fond du problème qui est qu'à mon avis, si quelqu'un ne connait rien en PHP,
il vaut mieux lui apprendre PHP plutôt qu'un langage maison. Nonobstant les qualités intrinsèques de SPIP,
bien que PHP ne me transporte pas d'élégance, il des avantages certains sur ce qu'on pourrait inventer incrémentalement.
Là tu fais une identification un peu rapide entre le créateur
(humain) et son oeuvre (le code). Pour tes neurones, c'est plus
simple de parser
#A = #B
que
<xml><a>[!CDATA #B]</a></xml>
à la base, ct pour simplifier l'ecriture à la fin, pas au début...
le code, c'est moi qui le crée
donc c'est mes neuronnes qui doivent faire un parser,
donc c'est moi qui doit parser...
bien sûr que le xml est pas vachement parlant. J'avais commencé par des tableaux php et je te jure que ct encore moins parlant
>
> Simplifier aux deux bouts c'est encore mieux.
bah, j'ai commencé par un bout, mais si tu me dis que ca va arreter tout le monde, alors je prendrais l'autre bout aussi :_(
C'est fait pour eviter au gens qui y connaissent rien en php à
tapper du php pour avoir un alias.
On arrive au fond du problème qui est qu'à mon avis, si quelqu'un ne
connait rien en PHP, il vaut mieux lui apprendre PHP plutôt qu'un
langage maison. Nonobstant les qualités intrinsèques de SPIP, bien
que PHP ne me transporte pas d'élégance, il des avantages certains
sur ce qu'on pourrait inventer incrémentalement.
Je suis absolument conscient du pbl, je ne pense pas qu'obliger à apprendre à qq un nouveau langage soit une bonne solution.
Il reste que faire du SPIP c'est plus simple que du php, et apprendre du SPIP c'est plus simple que d'apprendre du php.
Avoir des extensions qui font un mapping spip vers php, comme les nouvelles balises, permet à certain d'utiliser leurs connaissances dans un langage libéré comme php pour offrir à d'autres des outils avec gardes fous integrés.
C'est fait pour eviter au gens qui y connaissent rien en php à
tapper du php pour avoir un alias.
On arrive au fond du problème qui est qu'à mon avis, si quelqu'un ne
connait rien en PHP, il vaut mieux lui apprendre PHP plutôt qu'un
langage maison.
Je partage ce dernier point de vue, et je crois utile de préciser mes intentions en ce qui concerne le nouveau compilateur.
Spip utilise le mot "balise" a toutes les sauces, puisqu'il s'applique:
- aux constructions à la HTML comme "<INCLURE ...", "<cadre>" etc;
- aux valeurs SQL dites "champs valides" naguère, et à toute valeur SQL aujourd'hui;
- aux constructions spécifiques s'apparentant syntaxiquement aux champs SQL, comme EXPOSER, FORMULAIRE_*, LOGO_* etc.
Le nouveau compilateur a permis d'évacuer la notion de "champ valide" nécessaire pour promouvoir un "champ SQL" en un "champ Spip".
Dans sa dernière version, il a permis de ramener les FORMULAIRE_* a un cas particulier d'inclusion,
en ajoutant quelques filtres dans la bibliothèque standard.
Pour moi, la tendance à terme est de considérer que toute écriture de la forme "#xxxx" référence
une valeur de table (les tables SQL standard y compris la table des meta, les tables SQL externes,
plus la pseudo-table que sont les valeurs envoyées par HTTP), les filtres servant a réécrire la valeur brute quand elle ne convient pas. A ce titre, il ne devrait pas y avoir dans le compilateur de traitement particulier des balises de forme "#xxx": il serait beaucoup plus clair de n'avoir que des valeurs SQL ou HTTP sur lesquels s'appliquent des filtres. Le "langage Spip" s'apprendrait et compilerait alors beaucoup plus facilement.
Il y a encore des balises qui échappent à ce cadre général, mais en ce qui me concerne je cherche à les éliminer d'une part, et à rationnaliser la déclaration des filtres d'autres part car c'est là que se situe le plus grand besoin de clarification à présent. On comprendra donc que de mon point de vue (mais ce n'est que mon point de vue, chacun en fait ce qu'il veut) les contributions qui visent à démultiplier les balises ne vont pas dans le bon sens. Pour moi, il faut simplifier le langage en se fondant sur un petit nombre de notions, surtout quand elles sont déjà connues, plutot que d'empiler des notions ad hoc peu distinctes les unes des autres. On peut faire un parallèle avec la problématique des processeurs à jeu d'instructions réduit ou large: l'architecture à jeu réduit a fait la preuve de sa supériorité parce qu'elle se maîtrise rapidement. C'est à mon avis l'exemple à suivre.
