[SPIP Zone] Questions sur une évolution de CFG

19eb0d0ad6f2ebee089f · Novembre 19, 2007, 10:56

Bonjour aux zonards,

Une balise
-----------
Vous le savez peut-être, j'essaie de coder une balise #FORMULAIRE_CFG afin de pouvoir utiliser des fonds de formulaire CFG depuis un squelette, public ou privé. Ca commence à tourner presque correctement.

J'ai ajouté un plugin cfg_exemples dans _tests_ afin de montrer des codes simples d'utilisation de cette nouvelle balise.

Tout retour est le bienvenu, notamment sur le nommage des balises et des arguments : c'est le moment de donner des noms explicites si ceux que j'ai appliqués ne vous semblent pas adaptés.

Un problème !
-------------
J'écris surtout car j'arrive face à un problème, du à la méthode utilisée pour transmettre des paramètres à CFG (#REM et <!--).

Il se trouve qu'avec a balise #FORMULAIRE_CFG et même parfois avec les fonds, les noms transmis avec <!-- ne sont pas pris en compte.

J'aurais bien essayé d'uniformiser cela.

Actuellement, CFG fait 2 traitements pour récupérer les paramètres :
- un premier pour récupérer les #REM
- un deuxième qui compile (recuperer_fond) pour récupérer les <!--, l'ensemble du formulaire cfg.

J'aimerai simplifier en ne faisant qu'un traitement qui compile, mais qui ne compile que la partie du fond qui contient les paramètres de CFG, pour éviter de lancer des calculs de boucles ou d'autres choses trop lourdes.

Je me disais qu'encadrer les paramètres CFG par une balise <cfg_params>
et éventuellement passer les arguments par <argument>valeur</argument> pourrait aller, il serait simple de capturer ce xml dans le fichier fond.

Mais ensuite ? comment lancer la machine à compilation puisqu'il n'y a pas de fichier à compiler, mais un texte simplement (écrire un fichier temporaire ?).

Seconde solution (me plait un peu moins, encore que !) : mettre un second fichier pour les fonds : fonds/cfg_mon_fond.html et fonds/params_mon_fond.html. Pour récupérer ses variables, CFG ne calculerait que params_mon_fond.html ?

Qu'en pensez-vous ?
Avez-vous des idées ?
(il va de soit que l'on garderait la compatibilité avec ce qui se fait actuellement)

MM.

azerttyu · Novembre 19, 2007, 11:02

S'lt

Pas vraiment d'avis mais l'idée de #REM c'est d'avoir tout au même
endroit, du coup l'idée 2 (faire un params_mon_fond) me semble pas
top.

Content que ça avance.

Km

touti · Novembre 19, 2007, 1:16

Matthieu Marcillaud a écrit :

Bonjour aux zonards,

Une balise
-----------
Vous le savez peut-être, j'essaie de coder une balise #FORMULAIRE_CFG afin de pouvoir utiliser des fonds de formulaire CFG depuis un squelette, public ou privé. Ca commence à tourner presque correctement.

J'ai ajouté un plugin cfg_exemples dans _tests_ afin de montrer des codes simples d'utilisation de cette nouvelle balise.

Tout retour est le bienvenu, notamment sur le nommage des balises et des arguments : c'est le moment de donner des noms explicites si ceux que j'ai appliqués ne vous semblent pas adaptés.

Un problème !
-------------
J'écris surtout car j'arrive face à un problème, du à la méthode utilisée pour transmettre des paramètres à CFG (#REM et <!--).

j'ai toujours trouvé curieux dans cfg de bricoler (même si c'est très bien fait) ce qui sert normalement aux commentaires,
je trouve que l'idée de balise spéciale est bonne, voir un simple <h2 id="titre_cfg"> paraitrait plus facile à comprendre
et à réutiliser ailleurs
mes 2 sous
touti

19eb0d0ad6f2ebee089f · Novembre 20, 2007, 5:10

toutati a écrit :

Matthieu Marcillaud a écrit :

Un problème !
-------------
J'écris surtout car j'arrive face à un problème, du à la méthode utilisée pour transmettre des paramètres à CFG (#REM et <!--).

j'ai toujours trouvé curieux dans cfg de bricoler (même si c'est très bien fait) ce qui sert normalement aux commentaires,
je trouve que l'idée de balise spéciale est bonne, voir un simple <h2 id="titre_cfg"> paraitrait plus facile à comprendre

Bonjour matinal,

Le problème sur #REM et <!-- est maintenant entièrement résolu (v.1.1.2). En fait, CFG doit nécessairement compiler tout le fond 2 fois :
1) pour récupérer
a) les paramètres
b) les noms des champs du formulaire
2) pour afficher le formulaire avec les valeurs des champs en questions passés dans l'environnement #ENV

Donc, il est inutile de vouloir compiler qu'un bout du squelette comme j'avais proposé pour ne récupérer que les paramètres, car au chargement de la classe CFG, cfg realise 1a) et 1b). Cependant, on pourrait faire 1b) qu'au moment du traitement du formulaire, mais quitte à compiler, autant tout faire d'un coup.

Tout cela permet de ne garder qu'une seule écriture pour les balises de paramètres cfg. #REM empèche les chaines de langues et autres balises, donc je propose de ne plus l'utiliser.

Il reste  qui peut être conservé tel quel ou modifié sous un autre nom... quelques idées (moi, je m'en fiche,  me convient très bien)

- <param nom='le_nom'>valeur</param> // risque de confusion avec flash
- <cfg param='nom'>valeur</cfg>
- 
-  // risque de confusion avec autodoc ?
...

Des commentaires, idées ?

MM.

Samy_RABIH · Novembre 20, 2007, 8:02

a l'avantage de vraiment trancher avec une syntaxe
de balises HTML standard, et puis ca facilite la lisibilité du code

-----Message d'origine-----
De : spip-zone-bounces@rezo.net [mailto:spip-zone-bounces@rezo.net] De la
part de Matthieu Marcillaud
Envoyé : mardi 20 novembre 2007 06:10
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Questions sur une évolution de CFG

toutati a écrit :

Matthieu Marcillaud a écrit :

Un problème !
-------------
J'écris surtout car j'arrive face à un problème, du à la méthode
utilisée pour transmettre des paramètres à CFG (#REM et <!--).

j'ai toujours trouvé curieux dans cfg de bricoler (même si c'est très
bien fait) ce qui sert normalement aux commentaires,
je trouve que l'idée de balise spéciale est bonne, voir un simple <h2
id="titre_cfg"> paraitrait plus facile à comprendre

Bonjour matinal,

Le problème sur #REM et <!-- est maintenant entièrement résolu
(v.1.1.2). En fait, CFG doit nécessairement compiler tout le fond 2 fois :
1) pour récupérer
a) les paramètres
b) les noms des champs du formulaire
2) pour afficher le formulaire avec les valeurs des champs en questions
passés dans l'environnement #ENV

Donc, il est inutile de vouloir compiler qu'un bout du squelette comme
j'avais proposé pour ne récupérer que les paramètres, car au chargement
de la classe CFG, cfg realise 1a) et 1b). Cependant, on pourrait faire
1b) qu'au moment du traitement du formulaire, mais quitte à compiler,
autant tout faire d'un coup.

Tout cela permet de ne garder qu'une seule écriture pour les balises de
paramètres cfg. #REM empèche les chaines de langues et autres balises,
donc je propose de ne plus l'utiliser.

Il reste  qui peut être conservé tel quel ou
modifié sous un autre nom... quelques idées (moi, je m'en fiche,  me convient très bien)

- <param nom='le_nom'>valeur</param> // risque de confusion avec flash
- <cfg param='nom'>valeur</cfg>
- 
-  // risque de confusion avec autodoc ?
...

Des commentaires, idées ?

MM.

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

3e5e4f242968084de82d · Novembre 20, 2007, 8:19

Samy RABIH a écrit :

a l'avantage de vraiment trancher avec une syntaxe
de balises HTML standard, et puis ca facilite la lisibilité du code

Perso, je serais pour eliminer cette syntaxe pour ne retenir que les balises, surtout si la compatibilité ascendante est rompue.
Deja l'utilisation de #REM qu'on fasse du commentaire, du filtre en partant d'une chaine vide ou de l'initialisation de variables de configuration, c'est pas clair.
Mais que des commentaires HTML dans les squelettes aient une influence sur la compilation... pour moi c'est à la limite dangereux.

@++

azerttyu · Novembre 20, 2007, 9:26

Bonjour

Ne peut on pas mettre param dans #REM ?

Une seule syntaxe pour cfg de conf : "tout dans REM", au moins on un
seul aspect illogique vis à vis de SPIP et pas 2

Km

19eb0d0ad6f2ebee089f · Novembre 20, 2007, 11:21

cam.lafit@azerttyu.net a écrit :

Bonjour

Ne peut on pas mettre param dans #REM ?

Une seule syntaxe pour cfg de conf : "tout dans REM", au moins on un
seul aspect illogique vis à vis de SPIP et pas 2

Non, on ne peut pas mettre tout dans #REM, c'est pour cela que je propose de carrément le déclarer absolete (à partir de cfg 1.1 donc).

Ceci pour 1 raison simple : si l'on met [(#REM) titre=<:plugin:titre:> ], à la compilation du squelette, tout ce qui est dans le #REM disparait et CFG ne peut plus le récupérer en analysant le texte.

--

Maintenant, pour revenir à ce que disait Stephane, il n'est pas question de rompre la compatibilité ascendente (au moins pas tout de suite) pour ne pas avoir à réécrire tous les fonds cfg... Il y a déjà assez de travail avec la future version de SPIP comme ça !.

Ceci n'empêche pas de proposer une écriture différente et plus logique pour les versions à venir.

Tiens, illumination subite :
Puisque le squelette est de toute façon compilé, on peut créer une balise pour cela aussi, mais c'est bien sûr !

#CFG_PARAM{...}

Il y a un inconvéient : on ne peut pas mettre de boucle dedans...

MM.

azerttyu · Novembre 20, 2007, 11:39

Je remet sur la liste

---------- Forwarded message ----------
From: Matthieu Marcillaud <marcimat@free.fr>
Date: 20 nov. 2007 12:21
Subject: Re: [SPIP Zone] Questions sur une évolution de CFG
To: "cam.lafit-LQsE5k9MKYjk1uMJSBkQmQ@public.gmane.org"
<public-cam.lafit-LQsE5k9MKYjk1uMJSBkQmQ@ciao.gmane.org>
Cc: Stephane <public-stephane-JM9gtpQu/Ho@ciao.gmane.org>

cam.lafit-LQsE5k9MKYjk1uMJSBkQmQ@public.gmane.org a écrit :

Bonjour

Ne peut on pas mettre param dans #REM ?

Une seule syntaxe pour cfg de conf : "tout dans REM", au moins on un
seul aspect illogique vis à vis de SPIP et pas 2

Non, on ne peut pas mettre tout dans #REM, c'est pour cela que je
propose de carrément le déclarer absolete (à partir de cfg 1.1 donc).

Ceci pour 1 raison simple : si l'on met [(#REM) titre=<:plugin:titre:>
], à la compilation du squelette, tout ce qui est dans le #REM disparait
et CFG ne peut plus le récupérer en analysant le texte.

--

Maintenant, pour revenir à ce que disait Stephane, il n'est pas question
de rompre la compatibilité ascendente (au moins pas tout de suite) pour
ne pas avoir à réécrire tous les fonds cfg... Il y a déjà assez de
travail avec la future version de SPIP comme ça !.

Ceci n'empêche pas de proposer une écriture différente et plus logique
pour les versions à venir.

Tiens, illumination subite :
Puisque le squelette est de toute façon compilé, on peut créer une
balise pour cela aussi, mais c'est bien sûr !

#CFG_PARAM{...}

Il y a un inconvéient : on ne peut pas mettre de boucle dedans...

MM.