[spip-dev] Critères {objet} {id_objet} et extension du critère ?

Dev
1

Bonjour,
deux petites questions sur les critères :

1/ existe-il déjà des critères {objet} et {id_objet} ou un équivalent permettant de spécifier une liaison. Je m'explique. Je prends l'exemple d'une noisette listant les mots clés associés à un objet.

Je voudrai faire une boucle du genre <BOUCLE_mots(MOTS){objet=article}{id_objet=12}> qui serait équivalent à <BOUCLE_mots(MOTS){id_article=12}>

En fait l'intérêt serait de pouvoir passer directement les infos à la noisette soit : <BOUCLE_mots(MOTS){objet=#ENV{objet}}{id_objet=#ENV{id_objet}}>

Du coup, je peux appeler la même noisette que ce soit pour les mots associés à un article, à une rubrique, ou à un nouvel objet toto créer par le plugin toto ou le nouvel objet que j'ai créé moi même.

En effet, l'écriture <BOUCLE_mots(MOTS){id_article ?}{id_rubrique ?}{id_breve ?}> est insuffisante car elle présuppose de connaitre déjà les liaisons possibles.

2/ A propos de ce critère ?, on ne peut l'utiliser que sur une variable d'environnement homonyme. Serait-ce possible de l'étendre (ou de trouver un équivalent) pour pouvoir utiliser aussi des variables calculées, par exemple quelque chose comme <BOUCLE_art(ARTICLES){id_rubrique=#GET{id_specifique}?}> ou <BOUCLE_art(ARTICLES){id_rubrique ? #GET{id_specifique}}>, le critère id_rubrique ne s'appliquant que si #GET{id_specifique} renvoie quelquechose.

Donc, pour ces deux cas de figures, existe-il déjà quelque chose (SPIP regorge d'oeufs de pâques).
Sinon, cela a-t-il sa place dans le core ou plutôt dans un plugin spécifique ?

Cordialement

Joseph

2

1/ existe-il déjà des critères {objet} et {id_objet}
<BOUCLE_mots(MOTS){objet=article}{id_objet=12}>

il est prévu (c'est dans dans les tuyaux, voir :
Connexion · GitLab)
que les tables mots_xxx soient remplacées par une table spip_mots_liens
(à l'image de spip_documents_liens). on pourra alors faire du :
   <BOUCLE_n(spip_mots_liens) {objet = article} {spip_articles.id_rubrique = 25}>

mais pour l'instant, en l'état, c'est pas possible.

2/ A propos de ce critère ?
<BOUCLE_art(ARTICLES){id_rubrique=#GET{id_specifique}?}>

mouais...
trés sale (dans le sens où plus lourd en terme de requête) :
   <BOUCLE_mots(ARTICLES) {id_rubrique == ^#GET{id_specifique, .+}$}>

3

1/ existe-il déjà des critères {objet} et {id_objet}
<BOUCLE_mots(MOTS){objet=article}{id_objet=12}>

il est prévu (c'est dans dans les tuyaux, voir :
Connexion · GitLab)
que les tables mots_xxx soient remplacées par une table spip_mots_liens
(à l'image de spip_documents_liens). on pourra alors faire du :
<BOUCLE_n(spip_mots_liens) {objet = article} {spip_articles.id_rubrique
= 25}>

mais pour l'instant, en l'état, c'est pas possible.

Mais ce n'est pas ça que j'évoquais. C'est l'ajout d'un critère {objet} et d'un critère {id_objet} valable sur n'importe quel boucle. Si ce critère est passé, alors on transforme la requête SQL en conséquence. Je ne sais pas si je suis plus clair. Je veux pouvoir faire ça sur une boucle MOTS (ou DOCUMENTS, ou n'importe quoi d'autre), indépendamment de la forme des tables de liaison (que SPIP gère très bien déjà).

2/ A propos de ce critère ?
<BOUCLE_art(ARTICLES){id_rubrique=#GET{id_specifique}?}>

mouais...
trés sale (dans le sens où plus lourd en terme de requête) :
<BOUCLE_mots(ARTICLES) {id_rubrique == ^#GET{id_specifique, .+}$}>

D'où la question de savoir s'il ne serait pas opportun de créer un nouveau critère ou d'élargir le critère ?. Et si oui, où cela aurait-il sa place ?

4

Mais ce n'est pas ça que j'évoquais. C'est l'ajout d'un critère {objet}
et d'un critère {id_objet} valable sur n'importe quel boucle.

ah d'accord. autant pour moi.
on pourrait effectivment envisager un critère (non homonyme
d'un champ sql existant, exit donc 'objet') à qui on passe 2 arguments :
le nom de la table et une valeur pour la clef primaire
   {joindre article,125}
ou
   {joindre #ENV{table},#ENV{val_id_table}}
ou bien encore (autre syntaxe) :
   {joindre id_article=125}
qui bâtirait la jointure de la table principale (celle entre
parenthèses) avec celle passée en paramètre du critère

où cela aurait-il
sa place ?

vu la portée générique de la fonctionnalité, dans le core assurément.
ce qui n'empêche pas un développement en plugin dans un premier temps.

très très très vite (sans vérification ni sécurisation),
ça pourrait donner (avec première syntaxe ci-dessus) :

function critere_joindre($idb, &$boucles, $crit) {
   // ici il manque plein de vérifs...

   // on récupère les paramètres du critère
   $params = $crit->param;

   // on extrait la table de jointure
   $join = $params[0][0]->texte;

   // on extrait le critère de jointure
   $on = $params[1][0]->texte;

   // on redéfini le critère dans une syntaxe
   // compréhensible par spip
   $crit->op = "=";
   $crit->param[0][0]->texte = "id_".$join;
   $crit->param[1][0]->texte = $on;

   // on balance dans le traitement général
   $r = calculer_critere_infixe($idb, $boucles, $crit);
   if (!$r) {
     return (array('zbug_critere_inconnu', array('critere'=>$crit->op)));
   } else {
     calculer_critere_DEFAUT_args($idb, $boucles, $crit, $r);
   }
}

(à peine testée sur 2.1.2)

5

Oui tout à fait, c'est bien ça l'idée.

Merci pour ta proposition

Joseph

6

je viens de trouver cela : http://programmer.spip.org/Criteres-optionnels-avec, comme quoi on en découvre tous les jours avec SPIP.

Par contre, ça ne fonctionne effectivement qu'avec une variable d'environnement homonyme. Je n'arrive pas à voir où c'est codé dans SPIP pour regarder s'il serait possible de l'étendre à #GET pour pouvoir faire :
<BOUCLEx(TABLES){nom ?operateur #GET{nom}}>

Joseph

7

oui oui bien sûr.
#ENV ou #GET pareil dès que champ et variable sont *homonymes*

8

oui.
et aussi sur http://www.spip.net/fr_article4013.html

9

A priori, en #GET ça ne fonctionne pas.

Si je fais un squelette simple :

#SET{id_article,15}
<BOUCLE_art(ARTICLES){id_article?<#GET{id_article}}>
<p>#ID-ARTICLE - #TITRE</p>
</BOUCLE_art>

J'obtiens tous les articles du site et pas seulement ceux avec un id inférieur à 15. Par contre, la même boucle fonctionne bien avec un #ENV.

Précision : testé sous SPIP 2.1.2.