[SPIP Zone] Variable pour l'objet d'une boucle ?

Archives Zone
1

Hello,

Suite à une discussion entre spipeur, on ce demandait s’il existait un moyen de passer l’objet d’une boucle en tant que variable, genre:

<BOUCLE_tableau(#GET{objet}){…}>
[…]
</BOUCLE_tableau>

Cela permettrait de créer des squelettes générique et d’éviter avec liste_truc, liste_machin, liste_brole. mais un liste_objet.

Des idées ?

Didier

2

Le 06.09.13 17:26, Debondt Didier a écrit :

Hello,

Suite à une discussion entre spipeur, on ce demandait s'il existait un
moyen de passer l'objet d'une boucle en tant que variable, genre:

<BOUCLE_tableau(#GET{objet}){..}>
[…]
</BOUCLE_tableau>

Cela permettrait de créer des squelettes générique et d'éviter avec
liste_truc, liste_machin, liste_brole. mais un liste_objet.

Des idées ?

Didier

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

A ma connaissance cela n'existe pas encore. Malheureusement :frowning:

--
Maïeul

3

Bonjour,

Le 6 sept. 2013 à 17:32, Maïeul <maieul@maieul.net> a écrit :

Le 06.09.13 17:26, Debondt Didier a écrit :

Hello,

Suite à une discussion entre spipeur, on ce demandait s’il existait un
moyen de passer l’objet d’une boucle en tant que variable, genre:

<BOUCLE_tableau(#GET{objet}){…}>
[…]
</BOUCLE_tableau>

Cela permettrait de créer des squelettes générique et d’éviter avec
liste_truc, liste_machin, liste_brole. mais un liste_objet

Des idées ?

Didier

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

A ma connaissance cela n’existe pas encore. Malheureusement :frowning:

Une boucle DATA ne pourrait pas faire ça, pour SQL par ex:

<BOUCLE(DATA){source format, données}> #BALISES

sql pour envoyer une requête brute au serveur SQL (utiliser {source sql, connecteur:requete} pour envoyer la requête sur une base externe)

La partie données semble pouvoir contenir des balises comme #ENV … mais se pose le pbm des noms des champs ensuite, puisque en fonction de la table c’est id_article, id_rubrique … vraiment à tester mais c’est vrai qu’une fois j’ai eu ce questionnement et j’arrive pas à retrouver ce que j’ai fait …

http://www.spip.net/fr_article5444.html

–
Maïeul
http://blog.maieul.net
http://geekographie.maieul.net

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

–
Pierre.

4

On ne peux pas vraiment dire que la boucle DATA soit vraiment une bonne idée, a quoi bon avoir un système qui gère des objets dans ce cas ?

Avoir la possibilité de gérer des objets via une variable me semble pourtant une excellente idée, pour SPIP 3.1 ?

Didier

Le 6 sept. 2013 à 17:55, Zapilou <csi@zapilou.com> a écrit :

Bonjour,

Le 6 sept. 2013 à 17:32, Maïeul <maieul@maieul.net> a écrit :

Le 06.09.13 17:26, Debondt Didier a écrit :

Hello,

Suite à une discussion entre spipeur, on ce demandait s’il existait un
moyen de passer l’objet d’une boucle en tant que variable, genre:

<BOUCLE_tableau(#GET{objet}){…}>
[…]
</BOUCLE_tableau>

Cela permettrait de créer des squelettes générique et d’éviter avec
liste_truc, liste_machin, liste_brole. mais un liste_objet

Des idées ?

Didier

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

A ma connaissance cela n’existe pas encore. Malheureusement :frowning:

Une boucle DATA ne pourrait pas faire ça, pour SQL par ex:

<BOUCLE(DATA){source format, données}> #BALISES

sql pour envoyer une requête brute au serveur SQL (utiliser {source sql, connecteur:requete} pour envoyer la requête sur une base externe)

La partie données semble pouvoir contenir des balises comme #ENV … mais se pose le pbm des noms des champs ensuite, puisque en fonction de la table c’est id_article, id_rubrique … vraiment à tester mais c’est vrai qu’une fois j’ai eu ce questionnement et j’arrive pas à retrouver ce que j’ai fait …

http://www.spip.net/fr_article5444.html

–
Maïeul
http://blog.maieul.net
http://geekographie.maieul.net

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

–
Pierre.

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

5

Le 08/09/2013 17:20, Debondt Didier a écrit :

On ne peux pas vraiment dire que la boucle DATA soit vraiment une bonne
idée, a quoi bon avoir un système qui gère des objets dans ce cas ?

Avoir la possibilité de gérer des objets via une variable me semble
pourtant une excellente idée, pour SPIP 3.1 ?

Non, ce n'est techniquement pas possible.

Pour que le compilateur puisse connaître les balises et critères relatifs à une boucle, il faut à la compilation qu'il connaisse le nom le l'objet de la boucle. Si on lui indique une variable, le compilateur ne pourra pas dire en analysant le squelette que le critère {truc} est inconnu (il ne peut pas savoir si truc appartient bien à l'objet, vu qu'il ne connaît pas à ce moment là l'objet).

La solution alternative est la boucle DATA, comme signalé par Maieul, mais évidemment on en revient aux mêmes problèmes : une boucle DATA ne râle jamais si on met une balise #CHOSE qui ne fait pas partie des données, vu qu'elle ne connaît pas non plus à la compilation la structure des données qu'elle recevra.

D'autre part… si tu mettrais #TITRE sur un objet qui attend un #NOM… est-ce que ça devrait afficher le titre ? ou rien du tout ? Est-ce que tu écrirais #TITRE|sinon{#NOM}|... ? et si l'objet a comme champ titre #TITLE … mince, …

Pour la plupart des objets, on ne peut pas prédire le noms de leurs champs (bon, pour le titre, on le peut : d'ailleurs, #INFO_TITRE{auteur, 2} ramènera effectivement le #NOM associé à l'auteur.)

MM.

6

Je me demande s’il ne serait pas utile d’introduire un nouveau truc dans SPIP, qui serait la compilation de squelettes se présentant sous forme de « chaînes » et non pas de « fichiers ». Ca permettrait de résoudre ça, et mille autres trucs.

7

Le 08.09.13 22:11, Fil a écrit :

Je me demande s'il ne serait pas utile d'introduire un nouveau truc dans
SPIP, qui serait la compilation de squelettes se présentant sous forme
de "chaînes" et non pas de "fichiers". Ca permettrait de résoudre ça,
et mille autres trucs.

-- Fil

tu pourrais préciser ta pensé ?

--
Maïeul

8

Je ne connait pas le fonctionnement du compilateur, mais:

Pour que le compilateur puisse connaître les balises et critères relatifs à une boucle, il faut à la compilation qu’il connaisse le nom le l’objet de la boucle. Si on lui indique une variable, le compilateur ne pourra pas dire en analysant le squelette que le critère {truc} est inconnu (il ne peut pas savoir si truc appartient bien à l’objet, vu qu’il ne connaît pas à ce moment là l’objet).

Ne peut ont pas justement l’informer de cet objet via une variable AVANT qu’il n’analyse la boucle, il n’y a pas de mécanisme de « precompilation » ?

D’autre part… si tu mettrais #TITRE sur un objet qui attend un #NOM… est-ce que ça devrait afficher le titre ? ou rien du tout ? Est-ce que tu écrirais #TITRE|sinon{#NOM}|… ? et si l’objet a comme champ titre #TITLE … mince, …

Je pense que c’est à la personne qui créé le squelette de respecter les champs de SPIP et de ne pas attendre que le système devine tout.

Didier

Le 8 sept. 2013 à 18:50, Matthieu Marcillaud <marcimat@rezo.net> a écrit :

Le 08/09/2013 17:20, Debondt Didier a écrit :

On ne peux pas vraiment dire que la boucle DATA soit vraiment une bonne
idée, a quoi bon avoir un système qui gère des objets dans ce cas ?

Avoir la possibilité de gérer des objets via une variable me semble
pourtant une excellente idée, pour SPIP 3.1 ?

Non, ce n’est techniquement pas possible.

Pour que le compilateur puisse connaître les balises et critères relatifs à une boucle, il faut à la compilation qu’il connaisse le nom le l’objet de la boucle. Si on lui indique une variable, le compilateur ne pourra pas dire en analysant le squelette que le critère {truc} est inconnu (il ne peut pas savoir si truc appartient bien à l’objet, vu qu’il ne connaît pas à ce moment là l’objet).

La solution alternative est la boucle DATA, comme signalé par Maieul, mais évidemment on en revient aux mêmes problèmes : une boucle DATA ne râle jamais si on met une balise #CHOSE qui ne fait pas partie des données, vu qu’elle ne connaît pas non plus à la compilation la structure des données qu’elle recevra.

D’autre part… si tu mettrais #TITRE sur un objet qui attend un #NOM… est-ce que ça devrait afficher le titre ? ou rien du tout ? Est-ce que tu écrirais #TITRE|sinon{#NOM}|… ? et si l’objet a comme champ titre #TITLE … mince, …

Pour la plupart des objets, on ne peut pas prédire le noms de leurs champs (bon, pour le titre, on le peut : d’ailleurs, #INFO_TITRE{auteur, 2} ramènera effectivement le #NOM associé à l’auteur.)

MM.

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

9

Mon idée, en pseudo-code, ce serait d’étendre la fonction récupérer_fond :

en plus de recuperer_fond($nom-du-squelette, $contexte), autoriser recuperer_fond($contenu-du-squelette, $contexte);
avec $contenu-du-squelette = '<BOUCLE(TRUC){toto} … ’

à priori c’est très simple à faire puisqu’« il suffit » d’enregistrer le squelette dans un fichier md5($contenu-du-squelette).html

Bien entendu, il faudrait aussi trouver comment nommer cette nouvelle fonction, faire des tests, faire de la doc, etc.

10

Le 08/09/2013 22:11, Fil a écrit :

Je me demande s'il ne serait pas utile d'introduire un nouveau truc dans
SPIP, qui serait la compilation de squelettes se présentant sous forme
de "chaînes" et non pas de "fichiers". Ca permettrait de résoudre ça,
et mille autres trucs.

Je ne sais pas si ça résoudrait le truc des boucles dynamiques, mais dans tous les cas, ce serait une super bonne chose ! Le compilateur serait non dépendant du système de fichier, et la compilation de fichiers-squelettes ne serait qu'un cas particulier de la compilation d'une chaîne en général.

Dans l'idéal, je trouverais cool que le compilateur puisse être un module autonome (pouvoir utiliser les squelettes sans rien installer de SPIP, sans base, sans tables, sans rien). Mais pour l'instant c'est tellement imbriqué avec le PATH, les plugins, etc...

--
RastaPopoulos

11

Le 09/09/2013 09:03, Fil a écrit :

Mon idée, en pseudo-code, ce serait d'étendre la fonction récupérer_fond :

en plus de recuperer_fond($nom-du-squelette, $contexte), autoriser
recuperer_fond($contenu-du-squelette, $contexte);
avec $contenu-du-squelette = '<BOUCLE(TRUC){toto} ... '

à priori c'est très simple à faire puisqu'"il suffit" d'enregistrer le
squelette dans un fichier md5($contenu-du-squelette).html

Bien entendu, il faudrait aussi trouver comment nommer cette nouvelle
fonction, faire des tests, faire de la doc, etc.

Ici, il y a recuperer_code() :

Et Connexion · GitLab qui s'en était inspiré.

MM.

12

Ça ne me parait pas très compliqué de faire une implémentation rapide comme tu le dis, en générant à la volée un fichier squelette md5 correspondant à la chaine passée en fond. Pour détecter que c’est une chaine, il suffirait de se baser sur la présence d’un des caractères « <>#(){}\n » dans le fond et de décider alors que ce n’est pas un fichier (mais ça peut créer quelques incompatibilités si certains utilisent des noms de squelettes bizarres…)

La question qui vient ensuite est de savoir si c’est pertinent de créer un fichier intermédiaire à la volée. Ça a un coût perf, et on peut se dire que c’est inutile, du moment que le squelette compilé est bien mis en cache. Mais on peut voir ça comme une première étape, en attendant de répercuter dans le compilateur l’ensemble des modifs pour accepter le squelette sous forme de chaine dans la cascade des fonctions concernées.

Je ne sais pas si ça résout la question initiale de ce thread, mais c’est une fonctionnalité qui serait surement utile.

Cédric

13

Le 9 sept. 2013 à 09:40, Matthieu Marcillaud <marcimat@rezo.net> a écrit :

Ici, il y a recuperer_code() :

Ah ben voilà, je l’avais oubliée !

Cédric

14

a du coup ca permettrait de faire des morceaux de chaînes dynamiques. Et on pourrait même pour le coup créer ces chaîne via un squelette. Je comprend mieux

Le 9 sept. 2013 à 09:03, Fil <fil@rezo.net> a écrit :

Mon idée, en pseudo-code, ce serait d'étendre la fonction récupérer_fond :

en plus de recuperer_fond($nom-du-squelette, $contexte), autoriser recuperer_fond($contenu-du-squelette, $contexte);
avec $contenu-du-squelette = '<BOUCLE(TRUC){toto} ... '

à priori c'est très simple à faire puisqu'"il suffit" d'enregistrer le squelette dans un fichier md5($contenu-du-squelette).html

Bien entendu, il faudrait aussi trouver comment nommer cette nouvelle fonction, faire des tests, faire de la doc, etc.

-- Fil

2013/9/8 Maïeul <maieul@maieul.net>
Le 08.09.13 22:11, Fil a écrit :

Je me demande s'il ne serait pas utile d'introduire un nouveau truc dans
SPIP, qui serait la compilation de squelettes se présentant sous forme
de "chaînes" et non pas de "fichiers". Ca permettrait de résoudre ça,
et mille autres trucs.

-- Fil

tu pourrais préciser ta pensé ?

--
Maïeul
http://blog.maieul.net
http://geekographie.maieul.net

15

2013/9/9 Cédric Morin <cedric@yterium.com>

Ça ne me parait pas très compliqué de faire une implémentation rapide comme tu le dis, en générant à la volée un fichier squelette md5 correspondant à la chaine passée en fond. Pour détecter que c’est une chaine, il suffirait de se baser sur la présence d’un des caractères « <>#(){}\n » dans le fond et de décider alors que ce n’est pas un fichier (mais ça peut créer quelques incompatibilités si certains utilisent des noms de squelettes bizarres…)

Ouh là attention danger. Il faut plutôt changer la signature ou le nom de la fonction pour traiter l’appel « recupérer un fond indiqué en chaine » (bref en gros il faudrait lui trouver un nom :wink: ).

recuperer_code() c’est pas mal, pas plus incompréhensible en tout cas que recuperer_fond() :))

Se pose aussi la question du remplissage du cache… (bien que avec memoization, le problème disparaîtra).

– Fil

16

Le 9 sept. 2013 à 12:21, Fil <fil@rezo.net> a écrit :

Se pose aussi la question du remplissage du cache… (bien que avec memoization, le problème disparaîtra).

Ah ça me rappelle que c’est ça qu’il faut faire dans la branche dev : remplacer la méthode de gestion actuelle du cache par celle de filecache du plugin memoization, plus robuste et plus rapide !

Cédric