Bonjour,
J’ai une problématique sur la recherche :
Je voudrais pouvoir mélanger des rubriques et des articles triés par points.
Il me manque malheureusement un lien entre les boucles…
exemple :
<BOUCLE_rubriques(RUBRIQUES){recherche}{!par points}{doublons aff}>
<BOUCLE_test(ARTICLES){recherche}{points>#POINTS}> #URL_ARTICLE
</BOUCLE_test> #URL_RUBRIQUE
</BOUCLE_rubriques>
<BOUCLE_test_2(ARTICLES){recherche}{!par points}{doublons aff}> #URL_ARTICLE
</BOUCLE_test_2>
Le code retourné par une boucle recherche est ainsi :
SELECT articles.id_article, resultats.points AS points, articles.titre, articles.lang
FROM spip_articles AS articles
INNER JOIN spip_resultats AS resultats ON ( resultats.id = articles.id_article )
WHERE (articles.statut = ‹ publie ›)
AND (articles.date < ‹ 9999-12-31 ›)
AND recherche=‹ xxxxxxx ›
ORDER BY points DESC
Il me faut donc avoir une condition en plus dans mon where du style ‹ AND points opérande valeur ›.
Malheureusement je n’arrive pas à écrire ce critère…
Auriez-vous des solutions pour moi ou des pistes afin que je me sorte de ça ?
Après quelques vérifications, il se trouve que le critère est bien reconnu, le résultat affiché est correct, sauf que j'ai une erreur "Erreur sur le site | boucle critère inconnu points"
Info : J'ai le plugin full text activé.
SELECT articles.id_article, resultats.points AS points, articles.titre, articles.lang
FROM spip_articles AS `articles` INNER JOIN spip_resultats AS resultats ON ( resultats.id = articles.id_article )
WHERE (articles.statut = 'publie')
AND (articles.date < '9999-12-31')
AND recherche='xxxxxxxxx'
AND (points > 1)
Le 16 juin 09 à 19:19, Quentin <shaphyr@gmail.com> a écrit :
Après quelques vérifications, il se trouve que le critère est bien reconnu, le résultat affiché est correct, sauf que j'ai une erreur "Erreur sur le site | boucle critère inconnu points"
Info : J'ai le plugin full text activé.
SELECT articles.id_article, resultats.points AS points, articles.titre, articles.lang
FROM spip_articles AS `articles` INNER JOIN spip_resultats AS resultats ON ( resultats.id = articles.id_article )
WHERE (articles.statut = 'publie')
AND (articles.date < '9999-12-31')
AND recherche='xxxxxxxxx'
AND (points > 1)
Oui je sais, ce que je cherche à faire est bien un nouveau critère, ou du moins à le déclarer afin qu’il reconnaisse la condition.
Le sql généré automatiquement, sans rien faire est correct, c’est juste l’erreur qui me gène.
Car pour le moment on ne peut pas faire de conditions sur les points, seulement !par points ou par points.
Or je voudrais pouvoir faire des conditions la dessus… du genre points > 14 (exemple)
Après quelques vérifications, il se trouve que le critère est bien reconnu, le résultat affiché est correct, sauf que j’ai une erreur « Erreur sur le site | boucle critère inconnu points »
Info : J’ai le plugin full text activé.
SELECT articles.id_article, resultats.points AS points, articles.titre, articles.lang
FROM spip_articles AS articles INNER JOIN spip_resultats AS resultats ON ( resultats.id = articles.id_article )
WHERE (articles.statut = ‹ publie ›)
AND (articles.date < ‹ 9999-12-31 ›)
AND recherche=‹ xxxxxxxxx ›
AND (points > 1)
Oui je sais, ce que je cherche à faire est bien un nouveau critère, ou du moins à le déclarer afin qu'il reconnaisse la condition.
Le sql généré automatiquement, sans rien faire est correct, c'est juste l'erreur qui me gène.
Car pour le moment on ne peut pas faire de conditions sur les points, seulement !par points ou par points.
Or je voudrais pouvoir faire des conditions la dessus... du genre points > 14 (exemple)
Salut,
L'idée que l'on cherche a mettre en place (avec Quentin) c'est de pouvoir mélanger différents objets SPIP, dans une liste, qui plus est une liste de {recherche}.
Comment feriez-vous ? un nouveau critères qui permettrait d'écrire : {points > #POINTS} ou autre chose ?
Oui je sais, ce que je cherche à faire est bien un nouveau critère, ou du moins à le déclarer afin qu'il reconnaisse la condition.
Le sql généré automatiquement, sans rien faire est correct, c'est juste l'erreur qui me gène.
Car pour le moment on ne peut pas faire de conditions sur les points, seulement !par points ou par points.
Or je voudrais pouvoir faire des conditions la dessus... du genre points > 14 (exemple)
Salut,
L'idée que l'on cherche a mettre en place (avec Quentin) c'est de pouvoir mélanger différents objets SPIP, dans une liste, qui plus est une liste de {recherche}.
Vous l'auriez compris : mélangés mais aussi triés par pertinence ... ( quelque soit l'objet)
Oui je sais, ce que je cherche à faire est bien un nouveau critère, ou du moins à le déclarer afin qu’il reconnaisse la condition.
Le sql généré automatiquement, sans rien faire est correct, c’est juste l’erreur qui me gène.
Car pour le moment on ne peut pas faire de conditions sur les points, seulement !par points ou par points.
Or je voudrais pouvoir faire des conditions la dessus… du genre points > 14 (exemple)
Salut,
L’idée que l’on cherche a mettre en place (avec Quentin) c’est de pouvoir mélanger différents objets SPIP, dans une liste, qui plus est une liste de {recherche}.
Ce qui veut dire que nous pouvons arrêter de nous fatiguer c’est pas possible ou que notre quête sera longue ? Pourquoi la signification serait différente ? (Question par pur curiosité, pour comprendre comment ça marche) Toujours sur le même sujet, est-ce pertinent de vouloir mélanger ces objets et les trier ou cela n’a aucun sens (d’un point de vue SPIP) ? Cédric Morin a écrit :
Pas sûr que les #POINTS aient la même signification (pondération)
d'une table à l'autre
Pourquoi la signification serait différente ?
(Question par pur curiosité, pour comprendre comment ça marche)
Le plugin Fulltext par exemple, joue avec le nombre de champs indexés
dans chaque index fulltext de la table, et leur affecte des
pondérations *relatives* (le titre tout seul vaut 5 fois le
titre+texte, par exemple). La comparaison de 30 points pour un article
vs 10 points pour une rubrique n'est donc pas forcément "pertinente".
Toujours sur le même sujet, est-ce pertinent de vouloir mélanger ces objets
et les trier ou cela n'a aucun sens (d'un point de vue SPIP) ?
Le "point de vue SPIP" n'existe pas : c'est évident que ce serait
utile de pouvoir présenter des objets différents dans une même liste
paginée triée etc. Mais SPIP s'appuie sur SQL, et SQL ne permet pas ça
très facilement.
Ce qui veut dire que nous pouvons arrêter de nous fatiguer c’est pas possible ou que notre quête sera longue ?
La quête sera longue, c’est sur.
Votre approche n’est pas mauvaise cela dit, et a le mérite de la simplicité (du code sous jacent) au prix d’un squelette compliqué. Et elle ne permettra pas la pagination.
J’avais perso essayé d’arriver à cela via une boucle INDEX dans feu le plugin recherches_etendues, en spip 1.9.x
Je n’ai jamais rendu la fonction publique car elle est imparfaite, et faisait ressortir, par exemple, les articles non publiés.
Il serais sans doute vraisemblable de parvenir à quelque chose de voisin avec une boucle RESULTATS et une requete fabriquee un peu sioux. Mais avec le même probleme.
Le 17 juin 2009 15:18, Fil <fil@rezo.net> a écrit :
Pas sûr que les #POINTS aient la même signification (pondération)
d’une table à l’autre
Pourquoi la signification serait différente ?
(Question par pur curiosité, pour comprendre comment ça marche)
Le plugin Fulltext par exemple, joue avec le nombre de champs indexés
dans chaque index fulltext de la table, et leur affecte des
pondérations relatives (le titre tout seul vaut 5 fois le
titre+texte, par exemple). La comparaison de 30 points pour un article
vs 10 points pour une rubrique n’est donc pas forcément « pertinente ».
Oui, à partir du moment où un mixe les objets, il faut une pondération par type qui permet d’ajuster les pertinences. Je me souviens que j’avais typiquement le cas en mixant articles et documents dans le résultat de recherches.
