Bonjour,

JE cherche à mettre en place un formulaire de recherche avancé permettant de saisir dans un champ input x mots clés en écrivant une équation de type :
[mot1] ET [mot2]
ou encore : [ [mot1] OU [mot2] ] ET [mot3]

mais là je cale un peu au niveau des expressions régulières..
si qqun pouvait m'aiguiller
merci

Personnellement, je me simplifierais la vie
en effectuant deux explode() successifs avec pour delimiteurs : 'ET' et 'OU'

Hey ,

Oui on se simplifie la vie comme ça, mais ça reste un peu sale . Si tu regardais du côté des expressions régulières couplées à preg_match_all(). Je réfléchis à une expression sympa qui prendrait tous les cas, mais si tu as des parenthèses à gérer, les expressions régulières seront trop limitées … (Autrement dit : est-ce que tu as des parenthèses à gérer ?).

Enfin, la précédence des opérateurs est importante car théoriquement AND et plus fort que OR. C'est le cas pour toi ? Ça implique que sur a AND b OR c, on va d'abord regarder a AND b, puis utiliser le résultat avec OR c.

Merci pour ces réponses express.

Dans l'idéal, j'aurais des parenthèses à gérer (sinon j'ai aussi pensé à ce que l'utilisateur créé ses sous requêtes et fusionne les résultats après pour éviter les imbrications).

Bien sur je serais plus partisant du preg_match_all(), je pense me servir de cette fct pour d'autres formulaires.

merci

(Autrement dit : est-ce que tu as des parenthèses à gérer ?).

On dirait bien...

Lots of Insipid and Silly Parentheses

Le séparateur choisi [ n'est pas le mieux car il est utilisé dans les ereg, je peux mettre des $ ou tout autre séparateur...

Oui, [ ou (, c'est pareil. On a l'idée de regroupement.

@albat : LISP, Lost In Stupid Privatejoke ? Si tu n'as retenu que les parenthèses dans LISP (ou a fortiori dans Scheme), c'est bien dommage, car c'est une approche très intéressante. Et au moins, avec ce système de parenthèses, tu as une grammaire uniforme, pas de bidouille, toujours claire.

Tiens, je savais pas que tu étais passé sous Emacs..

Bonsoir,

à la première lecture de la question j'avais cru comprendre qu'il fallait transformer une chaine de caractères issue d'une saisie dans un formulaire en une requête "select".

du genre :
devient devient ... mais suite à la discussion qui a suivie j'ai un gros doute.
( à vrai dire je n'y comprends plus rien )

Peut-on me dire ?

Je viens de relire.
On n'est pas près de ramener quelque chose avec ça ...

C'était un petit coup de fatigue ...

En fait il faut récupérer les critères pour construire plusieurs requetes.
En résumé : j'ai une table avec des fiches , j'ai une table des mots et une table de liaison lien_fiche_mots (1 fiche possède 0 à x mots).
Pour accélérer mes requetes, je procède comme ceci :
j'isole mes id fiches pour chaque mot saisi et après entre chaque 'condition' entre les mots je fais des array_merge, array_diff...
En fait j'ai beacoup de mal à écrire correctement la requête qui interroge en une fois la table (bien qu'en ayant mis des index sur les mots, cela rame à mort).

J'espère que c'est assez clair ?

(Désolé pas logué)

En fait il faut récupérer les critères pour construire plusieurs requetes.
En résumé : j'ai une table avec des fiches , j'ai une table des mots et une table de liaison lien_fiche_mots (1 fiche possède 0 à x mots).
Pour accélérer mes requetes, je procède comme ceci :
j'isole mes id fiches pour chaque mot saisi et après entre chaque 'condition' entre les mots je fais des array_merge, array_diff...
En fait j'ai beacoup de mal à écrire correctement la requête qui interroge en une fois la table (bien qu'en ayant mis des index sur les mots, cela rame à mort).

J'espère que c'est assez clair ?

Hey ,

Alors, j'ai réfléchis de mon côté et je suis arrivé à la conclusion partielle suivante. Comme je le pensais, la syntaxe des expressions régulières Perl (et a fortiori PHP) ne permet pas de déborder sur un langage algébrique (comme on peut pouvait s'y attendre …). Les conséquences immédiates sont qu'on ne peut pas vérifier la validité de l'expression donnée par l'utilisateur. Typiquement, on ne peut pas compter les crochets (respectivement [ et ]), i.e. vérifier qu'il y a autant de [ que de ]. On pourrait bien sûr avec substr_count() mais c'est sale, ce n'est pas la meilleure façon d'opérer.

On peut y arriver, mais il faut développer plus de moyens (une sorte de parser léger pour des expressions logiques — et arithmétiques ? —). Je me demandais si c'était bien nécessaire. Pourquoi ne pas tout simplement faire un formulaire plus fournit en listes par exemple ? Car l'idée de laisser l'utilisateur écrire du pseudo-code-SQL me met mal à l'aise …

On peut y arriver, mais il faut développer plus de moyens (une sorte de parser léger pour des expressions logiques — et arithmétiques ? —). Je me demandais si c'était bien nécessaire. Pourquoi ne pas tout simplement faire un formulaire plus fournit en listes par exemple ? Car l'idée de laisser l'utilisateur écrire du pseudo-code-SQL me met mal à l'aise …

Je plussoie, je ne sais pas quel est le besoin initial mais la solution me semble surpensée (au risque du coup de ne jamais être utilisée à cause de sa complexité intrinsèque). En plus d'être assez longue à implémenter...

Tout cela est sans compter sur le preg_replace_callback() qui te simule non sans excellence une analyse syntaxique