[SPIP Zone] CFG, petites modifs...

Bonjour à tous :slight_smile:

Nouveau sur cette liste, je viens pour vous parler de quelques
petits ajouts que j'ai fait sur le plugin CFG que j'utilise
chez moi, sur la base de la dernière version en date (21/09/07).

En fait, récemment, pour des besoins persos, j'ai entrepris
d'explorer un peu les possibilités offertes par CFG, voir :
http://thread.gmane.org/gmane.comp.web.spip.devel/43450

J'ai ainsi pu découvrir une ou deux fonctionnalités fort utiles,
mais j'ai aussi remarqué quelques petites limitations, j'ai donc
décidé de chercher des solutions pour deux d'entre elles.

----------

- Masquer des onglets

La première contribution tente d'apporter une solution
au problème de l'encombrement, parfois inutile, de la page CFG
de l'espace privé. En effet, à force d'ajouter des formulaires
de configuration pour les squelettes, ou des plugins utilisant
les services de CFG, les onglets (boutons) se multiplient,
et ce phénomène ne peut que s'accentuer avec l'installation
d'autres contributions utilisant CFG.

Et comme CFG s'évertu à lister l'ensemble des fichiers portant
le préfixe "cfg_" se trouvant dans les dossiers "fonds/",
le nombre de ces onglets peut rapidement devenir gênant.

J'ai donc cherché une solution pour masquer les onglets
des formulaires dont la présence n'est pas indispensable,
et réduire ainsi l'encombrement des onglets.

Par exemple, si on souhaite réaliser quelques formulaires
de configuratin pour un squelette (ce qui est mon cas),
il n'est pas vraiment nécessaire que tous ces fichiers soient
listés comme onglets, on peut tout-à-fait en lister juste
les principaux, puis pour les autres prévoir des liens internes
entre formulaires correspondants au même plugin ou squelette.

Alors, la solution que j'ai trouvé, c'est d'ajouter un caractère
particulier aux noms des fichiers qu'on souhaite "masquer",
puis d'ajouter un petit test dans le code de CFG pour qu'il
ne tienne pas compte des fichiers contenant ce caractère.

Bien-sûr, j'ai aussi imaginé que certaines fois le renommage
des fichiers n'est pas souhaitable ou simplement réalisable,
alors on peut utiliser la solution du paramétrage du "titre" CFG,
c'est à dire l'utilisation de la balise "[(#REM) titre=xxx]" que
propose par défaut CFG, c'est en tout cas la méthode que
je préconiserait en premier.

Seul hic de ma solution, c'est que les titres des blocs dans les
formulaires, affichent tout de même le titre avec le caractère
spécial, celui permettant de masquer les onglets correspondants.

Alors, après plusieurs essais, j'ai pensé que le caractère le
moins gênant dans un titre, serait le point d'exclamation,
qu'on placerait à la fin du nom du fichier ou du "titre" CFG.

Alors, pour ceux à qui ça intéresse, voici le code, qui doit
être ajouté dans le fichier "plugins/cfg/exec/cfg.php",
à la ligne 175, juste après le bout de code suivant :

<code>
if ($tmp->titre)
  $titre = $tmp->titre;
else
  $titre = $fonds;
</code>

Voici le code de la contrib, avec les commentaires explicatifs :

<code>
// Si on souhaite masquer un fichier, c'est a dire,
// ne pas afficher l'onglet correspondant sur la page CFG
// de l'espace prive, il suffit de nommer le fichier
// avec un signe d'exclamation a la fin, juste avant
// l'extension ".html" : "cfg_test!.html".
// Si on ne souhaite pas modifier le nom des fichiers,
// on peut alors noter le titre a afficher avec la methode
// des "#REM" utilisee par CFG, toujours avec un point
// d'exclamation a la fin : [(#REM) titre=test !]
// Si jamais on desire afficher des titres avec un signe
// d'exclamation a la fin sans vouloir pour autant les masquer
// dans les onglets, il suffit alors d'ajouter une espace
// apres le point d'exclamation : [(#REM) titre=test ! ]
// NOTE ! cette contrib sert uniquement a masquer l'onglet
// des formulaires qu'on ne veut pas afficher sur la page CFG
// de l'espace prive, pour ne pas l'encombrer (inutiliement),
// mais les titres des formulaires seront toujours affiches
// avec le point d'exclamation à la fin, bien-sur, c'est un peu
// la raison du choix de ce caractere, un titre finissant par
// un point d'exclamation, ce n'est pas tres genant... :slight_smile:
// IMPORTANT ! cette methode fonctionne uniquement
// avec la syntaxe des balises "#REM", elle est inoperante
// avec la syntaxe des commenaires Html : <!-- titre=test !-->,
// ATTENTION ! pour pouvoir afficher ces formulaires masques,
// comme ils n'auront plus d'onglet, il faudra alors prevoir
// des liens vers eux dans les formulaires qui ont des onglets.
// FredoMkb - 09/07
if (strrpos($titre,"!") !== false
    && strrpos($titre,"!") == strlen($titre)-1)
        { continue; }
</code>

Bien-sûr, les commentaires ne sont nullement nécessaires
au bon fonctionnement du code.
Vous pouvez aussi mettre le code sur une seule ligne.

----------

- Variables dans les #REM

Cette autre contribution tente d'apporter une solution
au passage de variables contextuelles ou d'environnement
aux balises "#REM" de paramétrage de CFG.

En effet, en raison du mode de fonctionnement de CFG,
les balises "#REM" utilisées pour paramétrer certaines
options du plugin, ne permettent aucune inclusion de code
d'ynamique, sous la forme d'autres balises ou filtres,
ainsi qu'on peut le faire sur les autres balises.

En fait, les balies "#REM" de CFG sont "parsées" dans
le plugin avant que Spip ne puisse les traiter, du coup
il est impossible de modifier ces paramétrages de CFG
de manière dynamique.

Par exemple, si nous avons un premier formulaire listant
l'ensemble des auteurs du site, lorsque nous choisissons
un auteur, un autre formulaire s'affiche avec les différents
champs et variables de configuration à mémoriser.

Or, il pourrait être sympa, par exemple, de mettre le nom
de l'auteur dans le titre du formulaire, du genre :
"Configuration de Truc Muche".

Et comme le titre du formulaire est défini par une "#REM"
de CFG, du type : "[(#REM) titre=Configuration]", il aurait été
intéressant d'ajouter une balise dynamique, "#ENV" par ex.,
histoire d'ajouter le nom de l'auteur, sous la forme :
[(#REM) titre=Configuration de #ENV{auteur}]

Et bien, à cause du mode de travail de CFG, ceci est impossible.

Cette contrib tente donc d'apporter une solution pour
pouvoir mettre des variables dans les "#REM" de CFG.

La syntaxe retenue est en tout point semblable à celle utilisée
dans la plupart des balises "normales" de Spip, c'est à dire,
en inscrivant le nom de la variable à utiliser entre accolades,
ce qui donne : [(#REM) titre=Configuration de {auteur}].

On peut y inscrire une valeur statique par défaut, si jamais
la variable est intouvable dans les trois globales analysées,
à savoir "$_ENV", "$_GET" et "$_POST" respectivement.

La valeur par défaut se note pareil que pour la balise "#ENV",
c'est à dire séparée par une virgule de la variable cherchée :
[(#REM) titre=Configuration de {auteur,Fredo}]
Donc, si la variable "auteur" n'est pas trouvée, c'est "Fredo"
qui sera utilisé (enfin "Fredo" juste dans cet exemple :wink:

Évidemment, cet exemple de personnalisation du titre
du formulaire est un peu basique, mais on peut envisager
bien d'autres utilisations, comme le choix dynamique
du "casier" dans lequel la config sera enregistrée, etc.

Alors, toujours pour ceux à qui ça intéresse, voici le code
de cette contrib, qui doit être ajouté à la fin du fichier
"plugins/cfg/inc/cfg_formulaire.php", juste avant la dernière
accolade fermante du fichier, toujours avec les commentaires :

<code>

Re...

Bon... visiblement il y a une limite de longueur
pour les messages... voici donc la suite
manquante dans le post précédent :

----------

Alors, toujours pour ceux à qui ça intéresse, voici le code
de cette contrib, qui doit être ajouté à la fin du fichier
"plugins/cfg/inc/cfg_formulaire.php", juste avant la dernière
accolade fermante du fichier, toujours avec les commentaires :

<code>

Bon bein... pourquoi ça ne veut pas passer !? :frowning:

Allé, je tente encore une fois...

----------

<code>

Merdum de merdum :frowning: :frowning:

Ok... c'est la dernière tentative... après, dodo :wink:

----------

Code

Bonjour...

Je vais tenter d'envoyer la partie manquante
encore une fois, je ne pige pas pourquoi
elle ne veut pas passer... c'est bizarre :-/

---------

[code]
/*

Salut,

pour le truc des onglets, je ne sais pas (et il parrait que dans la
SVN, les onglets existent plus, mais j'ai pas essayer).

pour les variables de configuration du plugin, si tu veux utiliser des
constructions SPIP dedans (balises, boucles, chaines traduites,
etc...) tu peux faire avec un commentaire HTML et pas SPIP:
<!-- titre=Configuration de #ENV{auteur} -->
<!-- descriptif=<:monplugin:descriptif_cfg:> -->

il y a deux problèmes (bugs?) avec la notation en commentaires HTML,
c'est que le code qui crée les onglets n'arrive pas à les lire. Donc,
pour specifier le titre de l'onglet ou son icone, tu est obligé de
passer par #REM.

Pour le code, le plus simple serait soit:
1- de demander un accès svn au projet
2- d'envoyer des patchs attachés au mail.
Je ne sais pas trop qui s'oqp du code de cfg maintenant (:-/)

Pierre

On 9/27/07, FredoMkb <fredomkbfr@yahoo.fr> wrote:

- Variables dans les #REM

Cette autre contribution tente d'apporter une solution
au passage de variables contextuelles ou d'environnement
aux balises "#REM" de paramétrage de CFG.

En effet, en raison du mode de fonctionnement de CFG,
les balises "#REM" utilisées pour paramétrer certaines
options du plugin, ne permettent aucune inclusion de code
d'ynamique, sous la forme d'autres balises ou filtres,
ainsi qu'on peut le faire sur les autres balises.

Et comme le titre du formulaire est défini par une "#REM"
de CFG, du type : "[(#REM) titre=Configuration]", il aurait été
intéressant d'ajouter une balise dynamique, "#ENV" par ex.,
histoire d'ajouter le nom de l'auteur, sous la forme :
[(#REM) titre=Configuration de #ENV{auteur}]

C'est un peu tout le monde, sous le pilotage bienveillant de Marcimat ^^.

BoOz

Pierre Andrews a écrit :

Je ne sais pas trop qui s'oqp du code de cfg maintenant (:-/)

Re...
----------

[code]
/* Cette fonction r

BoOz a écrit :

C'est un peu tout le monde, sous le pilotage bienveillant de Marcimat ^^.

Tiens, c'est nouveau ça ? Je suis loin d'être bienveillant pourtant !

MM.

Bonjour Pierre :slight_smile:

Pierre Andrews <pierre.andrews@...> writes:

Salut,

pour le truc des onglets, je ne sais pas (et il parrait que dans la
SVN, les onglets existent plus, mais j'ai pas essayer).

Ha... ça je ne sais pas... j'ai travillé sur la dernière
version disponible dan la zone de téléchargement,
elle date du 21 septembre je crois...

pour les variables de configuration du plugin, si tu veux utiliser des
constructions SPIP dedans (balises, boucles, chaines traduites,
etc...) tu peux faire avec un commentaire HTML et pas SPIP:
<!-- titre=Configuration de #ENV{auteur} -->
<!-- descriptif=<:monplugin:descriptif_cfg:> -->

il y a deux problèmes (bugs?) avec la notation en commentaires HTML,
c'est que le code qui crée les onglets n'arrive pas à les lire. Donc,
pour specifier le titre de l'onglet ou son icone, tu est obligé de
passer par #REM.

En effet, j'avais aussi remarqué que les titres dans
les commentaries Hmtl ne fonctinnaient pas, mais
cette méthode semble ne fonctionner que pour les
données "affichables" (titre, descriptif, boite, etc),
pour les autres paramètres, tels que "nom", "casier",
"vue" etc, il faut passer par l'utilisation des "#REM",
c'est surtout dans ce cas de figure que cette contrib
tente d'apporter une solution...

Pour le code, le plus simple serait soit:
1- de demander un accès svn au projet
2- d'envoyer des patchs attachés au mail.
Je ne sais pas trop qui s'oqp du code de cfg maintenant (:-/)

Ok, à qui faut-il demander un accès Svn ?

Merci... à+ :slight_smile:
Fredo

Bon, je sais plus moi :-/

Quelqu'un pourrait m'expliquer pourquoi
je n'arrive pas à envoyer la seconde partie
de mon message ?

C'est quoi qui peut coincer de cette manière ?

Des pistes pour résoudre ce petit problème ?

C'est juste du texte que je tente de poster...
je pige pas là :frowning:

Merci...
Fredo

* FredoMkb tapuscrivait, le 27/09/2007 11:22:

Re...
----------

[code]
/* Cette fonction r

Fait un ticket et joint le fichier au ticket :wink:

--
RealET

On 9/27/07, FredoMkb <fredomkbfr@yahoo.fr> wrote:

Bonjour Pierre :slight_smile:

Pierre Andrews <pierre.andrews@...> writes:

>
> Salut,
>
> pour le truc des onglets, je ne sais pas (et il parrait que dans la
> SVN, les onglets existent plus, mais j'ai pas essayer).

Ha... ça je ne sais pas... j'ai travillé sur la dernière
version disponible dan la zone de téléchargement,
elle date du 21 septembre je crois...

SVN de SPIP donc, pas du plugin...

> pour les variables de configuration du plugin, si tu veux utiliser des
> constructions SPIP dedans (balises, boucles, chaines traduites,
> etc...) tu peux faire avec un commentaire HTML et pas SPIP:
> <!-- titre=Configuration de #ENV{auteur} -->
> <!-- descriptif=<:monplugin:descriptif_cfg:> -->
>
> il y a deux problèmes (bugs?) avec la notation en commentaires HTML,
> c'est que le code qui crée les onglets n'arrive pas à les lire. Donc,
> pour specifier le titre de l'onglet ou son icone, tu est obligé de
> passer par #REM.

En effet, j'avais aussi remarqué que les titres dans
les commentaries Hmtl ne fonctinnaient pas, mais
cette méthode semble ne fonctionner que pour les
données "affichables" (titre, descriptif, boite, etc),
pour les autres paramètres, tels que "nom", "casier",
"vue" etc, il faut passer par l'utilisation des "#REM",
c'est surtout dans ce cas de figure que cette contrib
tente d'apporter une solution...

"vue", je sais mm pas ce que ça fait, mais "nom" et "casier" sont
utilisées pour spécifier l'identifiant des valeurs à stoquer dans la
config. ça me parrait un peu étrange de vouloir qu'elles soient
"variables"...

Ok, à qui faut-il demander un accès Svn ?

il faut lire la charte de la zone, comprendre, accepter et un mail sur
cette liste suffit à réveiller les admins en géneral :wink:
S'il se reveille pas, demande à Gille Vincent...

Pierre

PS: prq ne pas mettre ton code en attachement déjà :wink:

Re...

RealET <real3t@...> writes:

> /* Cette fonction r
Fait un ticket et joint le fichier au ticket

Euh... un ticket sur Svn ?
Ok, mais il ne faut avoir un compte au préalable ?

Bref, je veux bien mais pardonnez-moi si je suis
un peu lourdaau au début, ce que je ne connais
pas du tout svn, donc, je risque de vous demander
un peu d'aide pour approvoiser la "bête" :wink:

Merci...
Fredo

* FredoMkb tapuscrivait, le 27/09/2007 11:45:

Re...

RealET <real3t@...> writes:

/* Cette fonction r

Fait un ticket et joint le fichier au ticket

Euh... un ticket sur Svn ?
Ok, mais il ne faut avoir un compte au préalable ?

Bref, je veux bien mais pardonnez-moi si je suis un peu lourdaau au début, ce que je ne connais pas du tout svn, donc, je risque de vous demander un peu d'aide pour approvoiser la "bête" :wink:

Les commit SVN et les tickets sont 2 choses différentes.
- Pour les commits, il vaut mieux faire un nouveau message ici pour dire que tu accepte la charte et que tu demande un accès (avec un titre explicite au message).
- Pour les tickets, tu vas sur Connexion · GitLab
En haut tu clique sur connexion
Tu t'inscrit
Tu reçois tes identifiants
Tu peux alors poster un nouveau ticket une fois identifié

--
RealET

FredoMkb a écrit :

- Masquer des onglets

Et comme CFG s'évertu à lister l'ensemble des fichiers portant le préfixe "cfg_" se trouvant dans les dossiers "fonds/", le nombre de ces onglets peut rapidement devenir gênant.

Oui, c'est vrai effectivement...

J'ai donc cherché une solution pour masquer les onglets des formulaires dont la présence n'est pas indispensable, et réduire ainsi l'encombrement des onglets.

Par exemple, si on souhaite réaliser quelques formulaires de configuratin pour un squelette (ce qui est mon cas), il n'est pas vraiment nécessaire que tous ces fichiers soient listés comme onglets, on peut tout-à-fait en lister juste les principaux, puis pour les autres prévoir des liens internes entre formulaires correspondants au même plugin ou squelette.

Alors, la solution que j'ai trouvé, c'est d'ajouter un caractère particulier aux noms des fichiers qu'on souhaite "masquer", puis d'ajouter un petit test dans le code de CFG pour qu'il ne tienne pas compte des fichiers contenant ce caractère.

Mettre un signe sur le nom du fichier pour dire qu'il n'a pas besoin d'apparaître dans les onglets (ce qui sous entend qu'il est inclu par un [(#REM) liens*=fond_inclu] dans un autre fond de cfg) me va parfaitement.

Le signe ! en fin du nom de fichier, ok... ça a l'air le plus simple...
Je ne vois pas par contre pourquoi on aurait besoin de proposer la même chose sur le titre ?

Autre question, est-il possible d'ajouter [(#REM) affichage_onglet=non] à la place des deux propositions (nom fichier et titre) ?

Bien-sûr, j'ai aussi imaginé que certaines fois le renommage des fichiers n'est pas souhaitable ou simplement réalisable,

Pourquoi ?

if (strrpos($titre,"!") !== false && strrpos($titre,"!") == strlen($titre)-1) { continue; }

La, je serais un peu plus prudent, mais je ne vois pas pourquoi quelqu'un ne mettrait pas un ! dans un titre...
Je vois bien quelqu'un venir demander "mais pourquoi mon fond, il s'affiche pas dans les onglets !?" simplement parce qu'il aurait mis un ! à la fin de son titre...

Une variable affichage_onglet ou un autre nom me semble vraiment plus simple si cela est possible...

- Variables dans les #REM

Cette autre contribution tente d'apporter une solution au passage de variables contextuelles ou d'environnement aux balises "#REM" de paramétrage de CFG.

On peut le faire avec <!-- titre=auteur #CONFIG{truc/auteur} ou #ENV{auteur} -->

Pierre dit que les onglets n'arrivent pas à lire ces titres là... je n'avais pas fait attention.

La syntaxe retenue est en tout point semblable à celle utilisée dans la plupart des balises "normales" de Spip, c'est à dire, en inscrivant le nom de la variable à utiliser entre accolades, ce qui donne : [(#REM) titre=Configuration de {auteur}].

On peut y inscrire une valeur statique par défaut, si jamais la variable est intouvable dans les trois globales analysées, à savoir "$_ENV", "$_GET" et "$_POST" respectivement.

_request() est ton ami en SPIP...
Là, pareil, si on peut éviter de nouvelles syntaxes et si on arrive à faire fonctionner uniquement avec #ENV{}, ce serait certainement plus simple, mais je suppose que tu y as réfléchi et que c'est pas évident.

MM.

On 9/27/07, FredoMkb <fredomkbfr@yahoo.fr> wrote:

Re...

RealET <real3t@...> writes:

> > /* Cette fonction r
> Fait un ticket et joint le fichier au ticket

Euh... un ticket sur Svn ?
Ok, mais il ne faut avoir un compte au préalable ?

Bref, je veux bien mais pardonnez-moi si je suis
un peu lourdaau au début, ce que je ne connais
pas du tout svn, donc, je risque de vous demander
un peu d'aide pour approvoiser la "bête" :wink:

pour creer un compte sur le wiki, c'est simple, t'as pas besoin de
demander sur la liste:
http://trac.rezo.net/spip_inscription.php3?mode=redac&focus=nom_inscription

Pierre

Pierre...

Pierre Andrews <pierre.andrews@...> writes:

> > pour le truc des onglets, je ne sais pas (et il parrait que dans la
> > SVN, les onglets existent plus, mais j'ai pas essayer).
>
> Ha... ça je ne sais pas... j'ai travillé sur la dernière
> version disponible dan la zone de téléchargement,
> elle date du 21 septembre je crois...

SVN de SPIP donc, pas du plugin...

Ha, je l'ignorais... désolé...

> En effet, j'avais aussi remarqué que les titres dans
> les commentaries Hmtl ne fonctinnaient pas, mais
> cette méthode semble ne fonctionner que pour les
> données "affichables" (titre, descriptif, boite, etc),
> pour les autres paramètres, tels que "nom", "casier",
> "vue" etc, il faut passer par l'utilisation des "#REM",
> c'est surtout dans ce cas de figure que cette contrib
> tente d'apporter une solution...

"vue", je sais mm pas ce que ça fait, mais "nom" et "casier" sont
utilisées pour spécifier l'identifiant des valeurs à stoquer dans la
config. ça me parrait un peu étrange de vouloir qu'elles soient
"variables"...

Pour ce que j'ai compris, "vue" sert à afficher un
formulaire autre que celui qui est dans le fichier appelé,
je ne sais pas exactement à quoi il pensais Toggg quand
il a implémenté cette option, mais ça devait sûrement
avoir un rapport avec "Crayons", qui semble utiliser
aussi cette technique. En tout cas, mes tests avec "vue"
n'ont rien donné, puisque les variables d'environnement
ne sont pas reconnus... bref, je n'ai pas tout pigé pour
être honnète...

Quant à "nom" et "casier", en effet, ils déterminent
l'espace logique, hiérarchique donc, dans leque les données
vont être sauvegardées.

Il peut être utile de pouvoir changer dynamiquement ces
valeurs, je pense surtout à "casier", dans le cas où
il y aurait un nombre important d'éléments à configurer,
on pourrait imaginer d'utiliser toujours le meme fichier
formulaire mais en changeant juste le "casier" de sauvegarde
par le Id de l'élément par exemple, c'est un peu ce que
je suis en train de faire pour mon projet de squelette.

Bien-sûr, Toggg avait déjà imaginé un mécanisme similaire,
avec la méthode "multi", mais elle ne fonctionne que sur
une arborescence à 2 niveaux seulement, tous mes tests
pour créer une hiérarchie plus flexible se sont soldés par
des echecs...

Bref, moi ça me sert dans mon projet, c'est pourquoi
j'ai pensé que ça pourrait intéresser d'autres que moi...

> Ok, à qui faut-il demander un accès Svn ?

il faut lire la charte de la zone, comprendre, accepter et un mail sur
cette liste suffit à réveiller les admins en géneral :wink:
S'il se reveille pas, demande à Gille Vincent...

Ok, j'y vais de ce pas lire la charte...
Puis j'adresse mon message de demande à Gilles Vincent, c'est ça ?

PS: prq ne pas mettre ton code en attachement déjà :wink:

Disons que je lis et écrits mes messages à partir
du web, http://news.gmane.org/gmane.comp.web.spip.zone
je ne reçois pas les messages chez moi, donc il m'est
impossible pour l'instant d'attacher des pièces jointes...

Merci pour l'aide... :slight_smile:
Fredo

Re...

RealET <real3t@...> writes:

Les commit SVN et les tickets sont 2 choses différentes.
- Pour les commits, il vaut mieux faire un nouveau message ici pour dire
que tu accepte la charte et que tu demande un accès (avec un titre
explicite au message).
- Pour les tickets, tu vas sur Connexion · GitLab
En haut tu clique sur connexion
Tu t'inscrit
Tu reçois tes identifiants
Tu peux alors poster un nouveau ticket une fois identifié

Ok, merci pour les infos... je tenterais de m'inscrire
cette aprème, et de proposer l'ensemble du code sur un ticket.

Merci...
Fredo

Ok, merci pour les infos... je tenterais de m'inscrire
cette aprème, et de proposer l'ensemble du code sur un ticket.

tu peux aussi le poster sur http://sh.nu/p

-- Fil