[spip-dev] Données hierarchiques avec CFG

Bonjour à tous :slight_smile:

Je me permet de poster ici ma question car je sais qu'il y a
des contributeurs bien familiarisés avec les subtilités du
développement avec le plugin CFG.

Alors, comme beaucoup d'autres, je cherche à modifier un squelette
pour pouvoir paramétrer certaines choses (affichage de certains
blocs, des titres, des pictos, etc.), et le plugin CFG est une
vraie merveille pour ça !

Seulement... et oui, seulement je n'arrive pas à trouver comment
faire pour hiérarchiser les infos à mémoriser, et apparement c'est
tout-à-fait possible, puisque notre regreté Toggg l'affirmait dans
l'article "Coder un plugin simple avec cfg"
(http://www.spip-contrib.net/Coder-un-plugin-simple-avec-cfg),
je cite :

"- valeur stocke un tableau php (array) contenant des éléments de
la forme : « nom_variable_config » => « valeur_de_la_variable ».
Ce tableau est enregistré sous sa forme sérialisée par spip, il
est récupérable aussi bien dans l’espace public que dans l’espace
privé. « valeur_de_la_variable » peut elle-même être un tableau
constitué de la même façon, ce qui permet d’obtenir des
arborescences de configuration."

Or, je souhaite justement hiérarchiser mes données avec des
tableaux impriqués, histoire d'affiner la récupération des données
dans le squelette et d'éviter d'avoir de nombreux fichier "cfg_xxx"
dans le répertoire "fonds/"...

En fait, je voudrais que l'ensemble des blocs "div" affichés par
le squelette puissent être personnalisables avec le même jeu de
paramètres, et comme il y a un bon paquet de blocs "div", je
voulais imaginer un formulaire de configuration CFG dynamique,
qui conserverait le "id" du bloc, et avec cet "id" l'ensemble des
paramètres à lui appliquer dans le squelette.

Concrètement, je voudrais structurer les données de la manière
suivante :

- Préfixe du squelette "aaa"
     - Bloc id "xxx"
          - Paramètre "titre" / valeur "oui"
     - Bloc id "yyy"
          - Paramètre "titre" / valeur "non"
     - Bloc id "zzz"
          - Paramètre "titre" / valeur "oui"
etc.

Donc, je voudrais que les données soient mémorisées sous la forme :

"aaa/xxx/titre"

Histoire de pouvoire faire :

[(#CONFIG{aaa/xxx/titre}|?{' ',''})<strong>Mon joli titre</strong>]

Or, mon problème est que les données sont mémorisées par CFG
suivant le nom du fichier formulaire Html, et je n'arrive pas à
trouver une solution pour n'utiliser qu'un seul fichier formulaire
pour tous les blocs "div" au lieu d'en faire un pour chaque bloc...

L'idéal serait de pouvoir indiquer à CFG la hiérarchie souhaitée
des données à mémoriser, peu importe le nom du fichier
formulaire utilisé... mais ça, je ne sais pas si c'est possible...
en tout cas, malgré pas mal d'heures de recherches,
je n'ai absolument rien trouvé :frowning:

Enfin, je ne sais pas si je suis assez clair dans mes explications...

J'espère que vous comprendrez ce que je cherche à faire...
car là, sans un peu d'aide, je ne m'en sortirais pas tout seul :frowning:

Merci à tous :slight_smile:
a+
Fredo

Bonjour à tous :slight_smile:

Bon, malgré une bonne partie de la nuit à chercher une manière
pour mémoriser des données de manière hiérarchique,
je n'ai malheureusement toujours rien trouvé :frowning:

Ok, je m'y prends peut-être mal, mais c'est surtout que
je n'ai pas bien compris encore quel est le mécanisme utilisé
pour mémoriser les données dans la table "meta" de Spip.

Ce que j'ai pigé, ou en tout cas j'ai l'impression d'avoir
compris, c'est que chaque nouvelle entrée dans la table porte
obligatoirement le nom du fichier de configuration.

Par exemple, si dans le dossier "fonds/" on a ces deux fichiers
formulaires :

- cfg_test.html
- cfg_test_config.html

Après validation de ces deux formulaires, on retrouve dans
la table "spip_meta" deux nouvelles entrées portant le nom,
respectivement, de "test" et "test_config".

Je crois que jusqu'à là c'est bon...

Maintenant, ce que je n'arrives pas à trouver, ni à comprendre
comment faire, c'est de n'avoir qu'une seule entrée de base,
"test" en l'occurrence, puis ajouter des "array()" associatifs
dans cette entrée, histoire de n'avoir, à la fin, qu'une seule
entrée dans la table "spip_meta", et toutes les infos
hiérarchisées à l'intérieur avec des tableaux...

Bref, je pattoge grave dans la semoule pour trouver la bonne
technique pour réaliser ça... :-/

Enfin, en désespoire de cause, j'ai adopté une solution
intermédiaire, c'est de nommer les clés de manière spécifique,
un peu à rallonge du coup, mais de cette manière j'arrive
à peu-près à trouver le comportement que je souahais.

C'est à dire, qu'au lieu d'avoir au final un truc du genre
(ce qui aurait été l'idéal en réalité) :

test (
     config (
          bloc1 ( titre => oui, picto => non ),
          bloc2 ( titre => non, picto => non ),
          bloc3 ( titre => oui, picto => oui )
     )
)

Du coup, j'ai du me contenter d'un truc comme ça :

test (
     config_bloc1_titre => oui,
     config_bloc1_picto => non,
     config_bloc2_titre => non,
     config_bloc2_picto => non,
     config_bloc3_titre => oui,
     config_bloc3_picto => oui
)

Bon, ça fonctionne un peu comme je voulais, mais avouez que ce
n'est pas très "sexy" comme solution :frowning:

Alors bon, si jamais quelqu'un trouvait la manière de mémoriser
les données de manière hiérarchique, je suis évidemment preneur !

Merci à tous :slight_smile:
a+
Fredo

Bonjour à tous :slight_smile:

Bon, voici la suite sur mes explorations du plugin CFG...

Ok, c'est pas facile ce truc... mon neronne est en surchauffe :wink:

Alors, j'ai trouvé un truc intéressant.

Avant je mémorisait mes données de configuration
en utilisant un nom de variable unique, puisque je n'avais
pas trouvé la manière de hiérarchiser les infos dans
des tableaux imbriqués... c'était un truc du genre :

<input type="hidden" name="ma_var_01" value="valeur01" />

Ce qui donnait, pour un fichier "cfg_test", quelque chose comme :

test (
     ma_var_01 => valeur01,
     ma_var_02 => valeur02,
     ma_var_03 => valeur03,
     etc...,
)

Du coup, je devais imaginer de noms de varialbes
un peu longs pour qu'ils soient effectivement uniques...

Donc, en cherchant un peu d'autres pistes, j'ai trouvé
qu'on pouvait mémoriser des données dans un "array",
il suffit de nommer la variable avec un "[]" à la fin :

<input type="hidden" name="ma_var[]" value="valeur" />

Ce qui donnait maintenant, toujours pour un fichier "cfg_test" :

test (
     ma_var => (
          0 => valeur01,
          1 => valeur02,
          2 => valeur03,
          etc...,
     ),
)

Et là, EUREKA, ça marche, j'ai enfin des tableaux imbriqués...
enfin, "des" n'est pas le bon mot, je devrais dire plutôt "deux" !

Et oui, j'ai tout essayé, mais rien à faire, je n'arrives pas
à trouver la bonne syntaxe pour imbriquer d'autres tableaux
dans ceux déjà crées... :frowning:

Pire encore, impossible de faire des tableaux associatifs... :frowning:

Voilà donc où j'en suis... j'ai pourtant essayé un paquet
de syntaxes, mais rien n'y fait... ça ne veut pas fonctionner...

Enfin, je tente encore d'avoir un peu de votre aide... si jamais
quelqu'un se penche un peu sur ce problème et qu'il trouve
une solution ou astuce pour obtenir enfin des enrgestrements
hiérachisés ave des tableaux associatifs de ce type :

test (
     ma_var => (
          ma_var_01 => valeur01,
          ma_var_02 => valeur02,
          ma_var_03 => valeur03,
          ma_var_04 => (
               ma_var_04_01 => valeur0401,
               ma_var_04_02 => valeur0402,
               ma_var_04_03 => valeur0403,
               etc...,
          ),
     ),
)

Et bien... je serais l'homme le plus content de la terre ;-)))

Merci à tous :slight_smile:
a+
Fredo

Bonsoir à tous :slight_smile:

Bon bon... comme dirait mon vieux, la persévérance fini
toujours par payer !

J'ai infin trouvé... en regardant en détail les fichiers Html
de fond fournis avec le plugin...

Mais bon, comme la doc n'est pas très explicite sur le rôle
exact de l'ensemble des fonctionnalités proposées par
le plugin, il faut procéder de manière empirique en testant
les différentes options jusqu'à comprendre leur utilité
et fonctionnement... à force on arrive par trouver... :slight_smile:
mais boun-diou, qu'est-ce que ça bouffe comme temps !

Alors bon, en résumé, voici ce que je viens de découvrir :

1. Pour utiliser toujours le même enregistrement dans
la table "spip_meta", quelque soit le nom du fichier
formulaire Html, il suffit de mettre en tête de celui-ci
le nom du "spip_meta" en question, avec cette syntaxe :

[(#REM) nom=nom_spip_meta]

Donc, si le formulaire de configuration se trouve dans
un fichier nommé "cfg_test.html" et qu'on souhaite
enregistrer la config dans le "spip_meta" nommé
par exemple "trucmuche", il suffit de noter en tête
du fichier formulaire la "remarque" Spip suivante :

[(#REM) nom=trucmuche]

Voilà déjà une bonne chose :slight_smile:

2. Alors, pour pouvoir imbriquer des tableaux
associatifs de configurations, là aussi, c'est aussi simple,
il suffit de noter en tête du fichier formulaire de config
le chemin logique du tableau final en utilisant la méthode
de "casier" de Cfg, avec une syntaxe de type :

[(#REM) casier=tableau_01/tableau_02]

Donc, si on souhaite avoir une arborescence de ce type :

test (
     ma_var => (
          ma_var_01 => valeur01,
          ma_var_02 => valeur02,
          ma_var_03 => valeur03,
          ma_var_04 => (
               ma_var_04_01 => valeur0401,
               ma_var_04_02 => valeur0402,
               ma_var_04_03 => valeur0403,
               etc...,
          ),
     ),
)

Il faut procéder par étapes, d'abord mémoriser
les variables "simples" du tableau principal "ma_var",
"test" étant le nom du "spip_meta", on fera donc :

[(#REM) nom=test]
[(#REM) casier=ma_var]

<input type="text" name="ma_var_01" value="valeur01" />
<input type="text" name="ma_var_02" value="valeur02" />
<input type="text" name="ma_var_03" value="valeur03" />

Puis, pour le tableau de la variable "ma_var_04", il faut
passer par un autre formulaire (ou le même si on peut
modiffier la valeur du "casier"), et y mettre :

[(#REM) nom=test]
[(#REM) casier=ma_var/ma_var_04]

<input type="text" name="ma_var_04_01" value="valeur0401" />
<input type="text" name="ma_var_04_02" value="valeur0402" />
<input type="text" name="ma_var_04_03" value="valeur0403" />

Voilà... je n'ai pas encore eu le temps de pousser mes tests
plus en détail, mais déjà avec ça je vais pouvoir enfin réaliser
mon petit bouzin à moi... :wink:

Enfin, j'espère que tout ceci pourra aider d'autres qui souhaitent
utiliser au meiux ce plugin génial qu'est CFG !

Merci à tous :slight_smile:
a+
Fredo

Enfin, j'espère que tout ceci pourra aider d'autres qui souhaitent
utiliser au meiux ce plugin génial qu'est CFG !

Bravo pour le reverse engineering. Je crois que ce serait pas mal que
tu sois auteur de la page de doc sur spip-contrib, pour pouvoir la
faire évoluer.

-- Fil

Bonsoir à tous :slight_smile:

Fil <fil <at> rezo.net> writes:

> Enfin, j'espère que tout ceci pourra aider d'autres qui souhaitent
> utiliser au meiux ce plugin génial qu'est CFG !

Bravo pour le reverse engineering. Je crois que ce serait pas mal que
tu sois auteur de la page de doc sur spip-contrib, pour pouvoir la
faire évoluer.

Merci Fil pour ta réponse... :slight_smile:

Avec plaisir, vraiment, pour compléter un peu la doc de ce plugin,
que je trouve, au risque de me redire, absolument génial !

Et puis, entre nous, si jamais mes petites découvertes sur CFG
peuvent aider d'autres Spipeurs à mieux comprendre ce plugin,
ce serait aussi pour moi une manière "utile" de rendre un modèste
hommage à tout le travail de développement réalisé par Toggg.

Mais... malheureusement, je suis loin, encore bien trop loin
d'avoir percé toutes les fonctionnalités et subtilités offertes
par CFG, c'est que Toggg avait bien imaginé le truc et avait
prévu un tas de situations et d'utilisations possibles...

Bref, je l'explore encore quelques temps, parce que je voudrais
faire certaines choses et je ne suis pas sûr que CFG les propose
par défaut... et je ne sais pas si sur la "zone" il y a encore
du monde qui suit le développement de ce plugin, ce serait
une bonne chose à mon avis...

Mais mon plus grand handicap est que mes connaissances en PHP
sont réellement très maigres, et le développement fait par
ce bougre de Toggg est d'un niveaux supérieur, bien trop élévé
pour un simple bidouilleur de mon type...

Tout y passe, développement orienté objet (chuis vraiment pas bon
dans ce domaine), utilisation et surcharge des fonctions du core,
appels par référence... et j'en passe... c'est du haut vol pour moi...

Alors bon, tout ça pour dire que je coince encore sur des trucs
qui peuvent paraître des banales broutilles pour des développeurs
de votre "carrure", mais je vais m'accrocher encore un temps,
car je pense sincèrement que c'est un plugin vraiment très utile,
il n'y a qu'à voir le nombre d'autres contributions qui s'en servent
pour s'en convaincre... alors je me dis que le temps passé
à l'explorer peut être très enrichissant et utile à l'avenir.

Fil, si jamais tu as un peu de temps, j'aimerais pouvoir te poser
quelques questions, toujours au sujet de CFG, au fur et à mesure
de mes recherches, car je suis sûr que tu pourrais m'aider un peu
à comprendre le rôle de certains bout de code, notamment ceux
qui font appel au model objet...

Bref, on reste en contact si tu le souhaites, et lorsque j'aurais
acquis un peu plus d'infos sur le fonctionnement de CFG, alors
je m'engage à rédiger un complément de doc sur Spip-Contrib,
promis !

Merci Fil :slight_smile:
a+
Fredo

Bonjour

Juste pour dire que mettre sur contrib ce (gros) bout de retour sera
déjà énorme.
C'est vraiment un gros boulot que tu as fait.

Sacré persévérance en tout cas.

Km

N'hésite pas. Le mieux c'est toujours de poser des questions sur la
liste spip-dev : ça permet à plus de gens de répondre, et à plus de
gens de lire les réponses ; en plus ça se trie et ça s'archive
automatiquement.

-- Fil

Re...

Merci les gars pour les encouragements !

Ok pour la doc, j'ai une semaine un peu chargée
(gros projet à finaliser), mais si le week-end
prochain est plutôt calme, je proposerai un premier
brouillon d'article sur Spip-Contrib, j'espère que
vous viendrez nombreux y jetter un coup d'oeil,
ne serait-ce que pour une rapide relécture, histoire
de ne pas publier trop de bêtises ou imprécisions...

Merci... je vous tiens au courant de la suite
de mes découvertes... ou de mes questions :wink:

à+
Fredo

PS. Fil, lorsque tu dis de poster sur "spip-dev",
j'ai comme un doute, "spip-dev" et "spip-devel"
c'est bien la même liste non ? ou j'ai tout faux ?

Re...

Fil <fil <at> rezo.net> writes:

N'hésite pas.

Ok, j'en profite donc :wink:

Comme on l'a vu pour la gestion des données hiérarchisées,
le plugin CFG conditionne un certain nombre d'options
et de fonctionnements suivant la présence de quelques
balises "#REM" existantes en tête des formulaires de config.

Pour connaître quelles sont les remarques existantes
dans les fichiers, le plugin lit la totalité du code
des formulaires Html, puis isole, grâce une fonction,
tous les paramètres passés par les balies "#REM".

Voici donc la fonction qui fait ça :

<code>
preg_replace_callback('/(\[\(#REM\) ([a-z0-9]\w+)(\*)?=)(.*?)\]/sim',
   array(&$this, 'post_params'), $this->controldata);
</code>

Comme on le voit, elle utilise une fonction "callback", que voici :

<code>
// callback pour interpreter les parametres objets du formulaire
// commun avec celui de set_vue()
function post_params($regs) {
  // a priori, eviter l'injection du motif
  if (isset($this->rempar)) {
    if (!isset($this->rempar[0][$this->current_rempar])
      >> $regs[1] != $this->rempar[0][$this->current_rempar++]) {
      die("erreur parametre interne: "
        . htmlentities(var_export($regs[1], true)));
    }
  }
  if (empty($regs[3])) {
      $this->{$regs[2]} = $regs[4];
  } elseif (is_array($this->{$regs[2]})) {
      $this->{$regs[2]} = $regs[4];
  }
  // plus besoin de garder ca
  return '';
}
</code>

Bon, n'étant vraiment pas famillier de l'utilisation
du model objet, j'ai le plus grand mal à savoir comment
ces infos sont mémorisés, comment et où en somme :-/

La syntaxe du "preg_replace_callback" est un peu particulière,
puisqu'elle utilise, comme argument désignant la fonction
"callback" justement, un "array"... et là... je suis pommé :frowning:

Que signifie la notation "&$this" dans cet array ?

Je m'y perd avec tous ces "this" propres aux devs orientées objet... :-/

De plus, dans la fonction "post_params", la syntaxe
"$this->{$regs[2]}" est aussi un peu bizarre pour moi...

Quel rôle ont dans ce cas les deux accolades "{" et "}" ?

Et puis, en l'état, cette fonction "post_params" ne retourne rien !?

Bref, à votre avis, où sont mémorisées les infos récupérées ?
Et, plus important, comment les récupérer par la suite ?

Quand je vous disais que j'étais juste un simple petit bricoleur,
(euh... qui a dit du dimanche ?), carrément nul en PHP :frowning:
vous en avez la preuve là :wink:

Bon, j'imagine que ces codes seuls ne sont pas suffisament explicites,
et qu'il faudra mettre le nez un peu dans le moteur du plugin pour
s'en faire une meilleure idée... il n'y a aucune urgence, mais si quelqu'un
avait quelques pistes pour clarifier un peu ces notions, ce serait super ! :slight_smile:

Au fait, le fichier contenant ces codes se trouve dans :
plugins/cfg/inc/cfg_formulaire.php

Merci de vos lumières :slight_smile:
a+
Fredo

Bonjour FredoMkb...

Tout d'abord merci pour avoir exploré CFG.
Je connaissais casier=qqc (j'étais absent pour te répondre), mais pas casier=qqc/dans/qqc, fort intéressant encore !

FredoMkb a écrit :

Comme on l'a vu pour la gestion des données hiérarchisées, le plugin CFG conditionne un certain nombre d'options et de fonctionnements suivant la présence de quelques balises "#REM" existantes en tête des formulaires de config.

Pour connaître quelles sont les remarques existantes dans les fichiers, le plugin lit la totalité du code des formulaires Html, puis isole, grâce une fonction, tous les paramètres passés par les balies "#REM".

Voici donc la fonction qui fait ça :

<code>
preg_replace_callback('/(\[\(#REM\) ([a-z0-9]\w+)(\*)?=)(.*?)\]/sim',
   array(&$this, 'post_params'), $this->controldata);
</code>

Bon, là, la traduction c'est grosso modo : chaque fois que tu trouves dans le texte [(#REM chose=truc], tu lances la fonction post_params...

En gros, c'est une expression régulière qui permet de trouver si #REM est présent dans la page ; elle renvoie un tableau avec ce qu'elle trouve, chaque élément du tableau est ce qui est trouvé dans les parenthèses de l'expression régulière... Un exemple car je ne suis pas clair : Soit l'expression simple : (abc)(defghi)(jkl). Si un texte est "abcdefghijklmnopq"... le tableau renvoyé sera : $tab[0] = tout, soit : "abcdefghijklmnopq" ; $tab[1] = "abc" (première parenthèse) $tab[2] = "defghi" , $tab[3]="jkl" ...

si on a : [(#REM) variable=valeur]
La fonction ici, en décortiquant, renvoie un tableau avec :
$reg[0] = tout le texte
$reg[1] = [(#REM) variable=
$reg[2] = variable
$reg[3] = * ou rien // je me demande à quoi sert cette étoile !! (Ah, à priori pour dire que c'est un tableau, mais bien sûr !)
$reg[4] = valeur

Le fait non pas de mettre directement le nom de la fonction en deuxième paramètre de preg_replace_callback, mais array(&$this, 'post_params'), permet d'utiliser 1) la fonction post_params de l'objet $this et 2) d'avoir accès aux variables de l'objet $this.

Le &$ indique un passage des valeurs par référence (PHP: Passage par référence - Manual), mais ce n'est pas la peine de t'embrouiller avec ça pour l'instant :wink:

L'important est de comprendre que la fonction post_params recoit les résultats de la recherche de #REM et comme elle est incluse dans l'objet, elle a accès aux variables de celui ci.

Comme on le voit, elle utilise une fonction "callback", que voici :

<code>
// callback pour interpreter les parametres objets du formulaire
// commun avec celui de set_vue()
function post_params($regs) {
  // a priori, eviter l'injection du motif
  if (isset($this->rempar)) {
    if (!isset($this->rempar[0][$this->current_rempar])
      >> $regs[1] != $this->rempar[0][$this->current_rempar++]) {
      die("erreur parametre interne: " . htmlentities(var_export($regs[1], true)));
    }
  }
  if (empty($regs[3])) {
      $this->{$regs[2]} = $regs[4];
  } elseif (is_array($this->{$regs[2]})) {
      $this->{$regs[2]} = $regs[4];
  }
  // plus besoin de garder ca
  return '';
}
</code>

Bon, n'étant vraiment pas famillier de l'utilisation du model objet, j'ai le plus grand mal à savoir comment ces infos sont mémorisés, comment et où en somme :-/

Je te passe la première partie if (isset($this->rempar)) {...}, j'ai pas ouvert le fichier et je ne sais plus à quoi ça sert (si jamais je l'ai su un jour !)

Ensuite, le script regarde si une étoile était présente (#rem variable*=valeur) et sinon : if (empty($regs[3])){} elle affecte $this->variable="valeur";

C'est ce que fait la ligne : $this->{$regs[2]} = $regs[4];
Les accolades donc remplacent $reg[2] par sa valeur ("variable")...

Remarque qu'on peut le faire sans accolade si ce n'est pas un tableau :
$a = "toto";
$this->$a = "titi"; est égal à $this->toto="titi";

Et puis, en l'état, cette fonction "post_params" ne retourne rien !?

Elle ne retourne rien effectivement, mais elle affecte dans l'objet $this toutes les valeurs de #REM qu'elle rencontre, et qui seront utilisées plus tard par des $this->nom ou $this->casier ...

En espérant t'éclairer un petit peu...

Bien chaleureusement et bon courage,
Matthieu.

juste pour confirmer qu'une des finalités des "rubrique-dossier" individuelles pour chaque contrib, sur SPIP-Contrib est justement de permettre de regrouper des apports divers, des angles de vues divers, sur un même sujet. Les explications d'un "utilisateur éclairé" peuvent ainsi être un très utile complément à la doc de l'auteur (par exemple). Un "ce plugin pour les nuls" vient très bien à coté d'un "les tripes du code à nu pour les devs".

Bref, à vos plumes, que vous soyez ou non le développeurs d'un contribution n'hésitez pas à proposer vos articles à coté de la doc "officielle" d'un plugin. Le travail de vulgarisation est aussi très nécessaire.

@+ NicolasR

Bonsoir Matthieu et à tous :slight_smile:

Matthieu Marcillaud <marcimat <at> free.fr> writes:

Bonjour FredoMkb...

Voici une "petite" réponse avec quelques observations
sur mon exploration de CFG...

Tout d'abord merci pour avoir exploré CFG.
Je connaissais casier=qqc (j'étais absent pour te répondre),
mais pas casier=qqc/dans/qqc, fort intéressant encore !

Oui, c'est en effet intéressant et finalement très pratique
pour structurer un minmum les données à sauvegarder
et à récupérer par la suite dans les squelettes par exemple.

Seul hic, mais qui est de taille à mon sens, c'est que les
balises "#REM" qui permettent de paramétrer le fonctionnement
de CFG, n'autorisent pas l'inclusion d'autres balises, histoire,
par exemple, de récuperer des valeurs dynamiques selon
le contexte ou les choix de l'utilisateur...

Du coup, une syntaxe de ce type est vouée à l'échec :

[(#REM) casier=liste_objets/[(#ENV{objet_id})]]

Le "parsage" de CFG se faisant avant tout interprétation
du code par Spip, aucune balise ou filtre ne fonctionne
dans les "#REM" propres à CFG... ce qui est bien dommage :frowning:

Conséquence logique, si on souahite, par exemple, configurer
et mémoriser des "préférences" pour des groupes rédactionnels,
avec un structure du genre :

groupes => (
         groupe_techinque => (
                  membres => ( Pierre, Paul, Jacques ),
                  prefs => (
                           rubriques => ( tests, informatique, Spip ),
                           mots => ( Ajax, Php, JavaScript )
         groupe_lettres => (
                  membres => ( Toto, Momo, Popo ),
                  prefs => (
                           rubriques => ( Romans, Poesies, Essais ),
                           mots => ( Goncourt, Femina, Nobel )
etc.

Il faut du coup créer des formulaires de configuration spécifiques
pour chaque groupe rédactionnel... pire, puisque chaque
sous-catégorie de préfs aura besoin de son propre formulaire,
étant donnée qu'on ne peut pas passer le chemin du bon "casier"
de manière dynamique directement dans la balise "#REM"...

Autrement dit, chaque niveau de l'arborescence aura besoin
d'un formulaire contenant le chemin "casier" qui lui correspond...
et dans un cas comme cet exemple, ça en fait déjà quelques
fichiers à préparer... :frowning:

Du côté du formulaire Html lui-même ce n'est pas tant un souci,
puisqu'on peut tout-à-fait prévoir des "modèles" tout prèts,
puis les utiliser par inclusion ou par la méthode "vue" de CFG,
quoi-que cette dernière technique s'avère, a priori (je n'ai pas encore
bien exploré toutes ses possibilités), moins souple si on désire
passer des paramètres dynamiques ou contextuels...

Le problème se situe surtout sur le nombre de fichiers "cfg_"
qu'il faudra créer dans le dossier "fonds/" pour couvrir l'ensemble
des niveaux de la hiérachie des données souhaitée... et comme
ces fichiers sont automatiquement listés sous forme d'autant
d'onglets dans la page CFG de l'espace privé, le tout peut devenir
rapidement encombrant avec les autres plugins utilisant CFG...

J'ai vainement cherché un moyen pour "masquer" certains fichiers,
mais CFG liste systématiquement tout fichier commançant par "cfg_"
et qui se trouvent dans le dossier "fonds/", et si jamais on enlève
le préfixe, CFG ne le reconnait tout simplement pas...

Bref, je découvre peu à peu les possibilités de CFG, qui sont
énormes et qui couvrent aisément les besoins les plus courants,
mais je découvre aussi quelques limitations, qui imposent
des choix un peu contraigants lorsqu'on désire réaliser des choses
un peu plus complèxes qu'une simple petite page de configuration...

Ceci étant dit, j'ai encore du pain sur la planche pour faire le tour
de la question, le plugin réserve encore d'autres surprises,
je dois dire que je suis sincèrement admiratif du boulot réalisé
par notre cher Toggg, tant par le niveau en développement
(qui est définitivement trop élévé pour moi), que par les idées
qu'il a su concrétiser... chapeau l'artiste !

J'espère, en tout cas je le souhaite vivement, qu'une équipe de devs
chévronnés prennent le relay et qui puissent dotter CFG des quelques
fonctionnalités supplémentaires, du côté des paramétrages
notamment, afin de le rendre un peu plus "souple" et "dynamique"
pour des besoins plus poussés ou spécifiques...

Du coup, une syntaxe de ce type est vouée à l'échec :

[(#REM) casier=liste_objets/[(#ENV{objet_id})]]

Je crois qu'on pouvait faire aussi
<!-- casier=liste_objets/[(#ENV{objet_id})] -->

(à tester)

-- Fil

Voilà qui me surprend. Si on a besoin de répérer un groupe des fichiers, par principe il faut créér un répertoire parce que tout le boulot de repérage est alors délégué au système d'exploitation, qui va faire ça en mode noyau (du binaire jamais en défaut de page) autrement dit ultra-rapidement comparé au poussif interprète PHP constamment interrompu. Je n'ai pas bien suivi le problème du masquage, mais dans le même ordre d'idées il faut sans doute organiser cet indispensable répertoire (disons cfg/ à la place de ce préfixe cfg_) avec des sous_repertoire dont on ignore certains quand on a besoin de "masquer" des choses.

Committo,Ergo:Sum

organiser cet indispensable répertoire (disons cfg/ à la place de ce
préfixe cfg_) avec des sous_repertoire dont on ignore certains quand
on a besoin de "masquer" des choses.

Oui ; on devrait d'ailleurs faire pareil pour organiser les
configurations/ de SPIP. Actuellement c'est un peu nul d'avoir une
page exec/configuration qui liste "en dur" les configuration/ à
activer.

-- Fil

Re...

Fil <fil <at> rezo.net> writes:

> Du coup, une syntaxe de ce type est vouée à l'échec :
>
> [(#REM) casier=liste_objets/[(#ENV{objet_id})]]

Je crois qu'on pouvait faire aussi
<!-- casier=liste_objets/[(#ENV{objet_id})] -->

(à tester)

En effet, j'ai déjà essayé, mais ça n'a pas l'air de fonctionner...

J'avais d'ailleurs jetté un rapid regard sur le code, et on dirait
que cette syntaxe, avec des commentaires Html, marche uniquement
pour les infos "affichables", du type "titre", "boite", "descriptif"...
mais pas avec les infos de paramétrage de CFG, du genre "casier"
"nom" ou "vue" (cf. "plugins/cfg/exec/cfg.php" "function sortie").

Ceci dit, il y a peut-être moyen, pour un dev qui aurait les
compétences en Php, d'ajouter les infos de paramétrage pour
une utilisation avec des commentaires Html... mais bon,
ce n'est peut-être pas aussi simple qu'on pourrait le penser...

... à suivre...

à+
Fredo

Re...

Committo,Ergo:sum <esj <at> rezo.net> writes:

>
> J'ai vainement cherché un moyen pour "masquer" certains fichiers,
> mais CFG liste systématiquement tout fichier commançant par "cfg_"
> et qui se trouvent dans le dossier "fonds/",

Voilà qui me surprend. Si on a besoin de répérer un groupe des
fichiers, par principe il faut créér un répertoire parce que tout le
boulot de repérage est alors délégué au système d'exploitation, qui
va faire ça en mode noyau (du binaire jamais en défaut de page)
autrement dit ultra-rapidement comparé au poussif interprète PHP
constamment interrompu. Je n'ai pas bien suivi le problème du
masquage, mais dans le même ordre d'idées il faut sans doute
organiser cet indispensable répertoire (disons cfg/ à la place de ce
préfixe cfg_) avec des sous_repertoire dont on ignore certains quand
on a besoin de "masquer" des choses.

Committo,Ergo:Sum

Oui, je me suis fait exactement la même réflexion, mais après
différents tests, il s'avèrerait (je préfère toujour parler
au conditionnel, n'étant pas assez "expert" pour assuer
que le résultat de mes essais soient absolument incontestables)...
il s'averairait donc, que le simple fait de créer un dossier,
démuni du préfixe "cfg_", est simplement ignoré par CFG.

Quan j'ai essayé de créer un dossier, disons "trucmuche",
puis en plaçant à l'intérieur des fichiers correctement préfixés,
"cfg_mon_formulaire.html" par exemple, CFG génère une erreur
en disant que le fichier "fonds/cfg_mon_formulaire.html" n'est
pas connu, alors qu'il devrait, normalement, répèrer le chemin
"fonds/trucmuche/cfg_mon_formulaire.html"... ce n'est pas le cas :frowning:

La seule solution pour organiser les fichiers dans des dossiers,
c'est lorsque ces fichiers sont utilisés par inclusion, mais
malheureusement pas lorsqu'ils font partie des fichiers de config.

... pas mieux pour le moment ...

à+
Fredo

FredoMkb a écrit :

Donc, à ce stade, si j'ai bien compris, ça veut dire que la valeur "{$regs[2]}" existe bien déjà en mémoire dans l'objet, pour pouvoir lui affecter une nouvelle valeur, "$regs[4]" en l'occurence... c'est ça ?

En théorie, oui...

Et puis, en l'état, cette fonction "post_params" ne retourne rien !?

Elle ne retourne rien effectivement, mais elle affecte dans l'objet $this toutes les valeurs de #REM qu'elle rencontre, et qui seront utilisées plus tard par des $this->nom ou $this->casier ...

Ok, mais nous sommes alors d'accord que ces "$this->nom" ou "$this->casier" ont déjà été crées dans l'objet, pour pouvoir leur affecter des nouvelles valeurs... ou alors, le simple fait de leur assigner une valeur les crée automatiquement ? ...
ce ne serait pas illogique après tout... mais là, je sais pas...

En théorie, oui, pour affecter $this->casier, il faut que la variable $casier soit déclarée dans la classe de l'objet...

En pratique, il me semble que si elle n'est pas déclarée, php ne râle pas et la crée sans discuter !!

Petit exemple pour s'en convaincre :

<?php
error_reporting(E_ALL);

class A{
  function A(){}
  
  function b(){
    $this->coucou = "toto";
  }
}

$a = new A();
# $a->b();
echo "Coucou : " . $a->coucou . "<br />";

?>

Ici, la variable coucou de la classe A n'est pas déclarée (var $coucou;) ni initialisée dans le constructeur (fonction A); En revanche, la fonction b() affecte "toto" à cette variable 'inconnue'.

Si on crée un objet $a de classe A, et que l'on tente de faire $a->coucou aussitôt ($a->b() commenté), php annonce une erreur légère : "Notice: Undefined property: A::$coucou" ...

Mais si on appelle la fonction b() avant, b() créant la variable sans quelle soit déclarée, là, aucun rapport d'erreur.

On peut donc, à priori, créer des variables à l'intérieur d'un objet sans qu'ils aient été déclarés au préalable, tant que c'est l'objet lui-même qui les crée (heu, je dis pas que c'est bien de faire comme ça, hein !! je dis que php, il ne râle pas ! - Je ne crois pas que cette façon de faire soit possible en java ou en c++, mais je connais pas vraiment pour l'affirmer !)

Bonjour Matthieu et à tous :slight_smile:

Matthieu Marcillaud <marcimat <at> free.fr> writes:

Pardon pour cette réponse un peu tardive, trop pris par ailleurs...

[...élagage...]

On peut donc, à priori, créer des variables à l'intérieur d'un objet
sans qu'ils aient été déclarés au préalable, tant que c'est l'objet
lui-même qui les crée (heu, je dis pas que c'est bien de faire comme ça,
hein !! je dis que php, il ne râle pas ! - Je ne crois pas que cette
façon de faire soit possible en java ou en c++, mais je connais pas
vraiment pour l'affirmer !)

Wouw wouw... ça c'est de l'explication !

Merci, c'est vraiment clair !

Donc, tant que c'est l'objet qui affecte une valeur à une variable,
alors qu'elle est inconnue, celà fonctionne en la créant à la volée,
mais si on tente de le faire de l'extérieur de l'objet... c'est l'erreur :frowning:

De plus, je viens de comprendre qu'en Php on nomme "objet"
une instance d'une "classe", je pensais que le mot "objet" désignait
la "classe" elle même... comme quoi, parfois on s'y perd sur des
simples broutilles de vocabulaire.

J'ai compris aussi, en regardant d'autres exemples, que le constructeur
de l'instance, de l'objet donc, est en fait une simple fonction, nommée
comme la classe (obligatoire ?), qui ne fait que ça en réalité... j'ai bon ?

Bref, très instructives tes explications... merci :slight_smile:

Pour revenir à CFG, si tu mets [(#REM) toto=truc], cfg va stocker dans
l'objet $this->toto="truc", mais, bien sûr, il ne l'utilisera pas vu que
cette variable n'est pas utilisée.

En effet, j'avais fait un ou deux tests, avec des "coucou=salut" ;-),
mais comme il n'y a rien de prévu dans CFG, elles sont ignorées.

Merci, à+ :slight_smile:
Fredo