Je suis persuadé que cela correspond à un besoin réel.
Je vais simplement prendre du temps pour réfléchir un peu correctement à ton sujet.

(Besoin réel: car la recherche actuelle est complète certe, mais trop complexe ce qui fait qu'aucun visiteur ne l'utilise et même moi, donc actuellement c'est idiot. Il faut que la "recherche rapide" soit rapide (la palisse dirait en plus "c'est à dire pas lent") et surtout repérable sur la page (pas dans un menu bien trop long).

Quelques remarques/réponses comme ça à la volée...

C'est recherche rapide ou recherche simplifiée (ou les deux)? ;-)

Les deux recherches seront-elles présentes? Si oui, on peut faire un onglet recherche simplifié et recherche rapide (avec affichage suivant $conf)

Pourquoi ne pas faire toutes les requêtes actuelles les une après les autres ou avec un union all? Que gagne-t-on avec les match...against (du temps, une meilleure rechercher + large[c'est des objectifs, si j'ai compris], ...)

Lors de la restitution des images, ne faudrait-il pas afficher la source de l'image (tag, auteur, etc.)

Si on garde les 2 recherches si la version de MySql n'est pas correcte, on peut ne pas afficher l'onglet recherche rapide

rub a écrit:

C'est recherche rapide ou recherche simplifiée (ou les deux)? ;-)

simple et rapide de point de vue l'utilisateur.

rub a écrit:

Les deux recherches seront-elles présentes? Si oui, on peut faire un onglet recherche simplifié et recherche rapide (avec affichage suivant $conf)

J'avais en tete une seule recherche, pas 2. Cette recherche vient s'ajouter a la fonctionnalite de recherche actuelle.

rub a écrit:

Pourquoi ne pas faire toutes les requêtes actuelles les une après les autres ou avec un union all? Que gagne-t-on avec les match...against (du temps, une meilleure rechercher + large[c'est des objectifs, si j'ai compris], ...)

Si je cherche "rub maison"  et que "rub" se trouve dans un tag et "maison" dans la description d'une categorie, avec ma requete t'auras en priorite les images avec le tag "rub" et la categorie "maison", alors qu'avec la tienne t'auras certainement tout, mais il y aura des non relevantes. J'y ai pense aussi d'interpreter la recherche et faire soit des union soit des intersect, mais le moteur sql le fait automatiquement.

rub a écrit:

Lors de la restitution des images, ne faudrait-il pas afficher la source de l'image (tag, auteur, etc.)

Je ne comptais pas modifier le template pour l'affichage, mais pourquoi pas dans un 2eme temps.

Alternative:
1 champ, 1 bouton et (au moins) 3 cases à cocher cochées par défaut:
tags, categories, images, pour définir vite fait les scopes de recherche.
La recherche actuelle peut passer en recherche avancée (mais fouillie :-))

je viens juste de voir le précédent message...

j'ai mis le fichier qsearch.php dans mon répertoire.... (partie sport, la plus grosse)

je ne suis pas sur que cela fonctionne.....  mais avec vos codes d'accés et vos statuts adviser vous pouvez si vous voulez allez voir ce que cela donne....

merci.
éric.

(je bosse dehors et ne lis pas les posts en direct pour un moment...)

Dernière modification par vimages (2006-08-10 18:37:55)

Ça ne marche pas :

J'ai demandé Jabouille et cela m'a retourné 7 images.
Le Tag m'en retourne 78...

Et cela a pris un peu moins de 8 secondes (pour les 7 images).

8-/

VDigital a écrit:

QSearch  Prost GT Jabouille
= 7 même images même temps de requête
Tag Prost + GT + Jabouille = 18 images

2 raisons possible:
1. le match against utilise le moteur MySql qui considere que tout mot qui contient moins de 4 caracteres (donc GT) est un "stop word" donc il est ignore.
2. est-ce que t'as les permissions a toutes les photos ? (dans l'etat la requete retourne les 15 premiers resultats, independement des permissions - donc si sur les 15 photos retournees, tu n'as pas acces a 8 alors seulement 7 seront affichees).