Expressions régulières pour requete booléene

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Expressions régulières pour requete booléene

par Sékiltoyai » 09 févr. 2009, 19:34

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

par Calimero » 09 févr. 2009, 15:41

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...

par Hywan » 09 févr. 2009, 15:05

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 :?

par _nico_13 » 05 févr. 2009, 10:13

(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 ?

par Invité » 05 févr. 2009, 10:12

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 ?

par blof » 05 févr. 2009, 07:20

Code : Tout sélectionner

SELECT * FROM la_table WHERE le_champ='mot1' AND le_champ='mot2' SELECT * FROM la_table WHERE (le_champ='mot1' OR le_champ='mot2') AND le_champ='mot3'
Je viens de relire. :shock:
On n'est pas près de ramener quelque chose avec ça ... :?

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

par blof » 04 févr. 2009, 21:24

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 :

Code : Tout sélectionner

[mot1] ET [mot2]
devient

Code : Tout sélectionner

SELECT * FROM la_table WHERE le_champ='mot1' AND le_champ='mot2'

Code : Tout sélectionner

[ [mot1] OU [mot2] ] ET [mot3]
devient

Code : Tout sélectionner

SELECT * FROM la_table WHERE (le_champ='mot1' OR le_champ='mot2') AND le_champ='mot3'
... mais suite à la discussion qui a suivie j'ai un gros doute.
( à vrai dire je n'y comprends plus rien )

Peut-on me dire ?

par Berzemus » 04 févr. 2009, 14:28

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

par Hywan » 04 févr. 2009, 12:54

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.

par _nico_13 » 04 févr. 2009, 12:52

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...

par albat » 04 févr. 2009, 12:49

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

Lots of Insipid and Silly Parentheses :roll: :twisted:

par _nico_13 » 04 févr. 2009, 12:46

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

par Hywan » 04 févr. 2009, 12:40

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.

par albat » 04 févr. 2009, 12:35

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

Expressions régulières pour requete booléene

par _nico_13 » 04 févr. 2009, 12:28

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