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

…
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 [i]a fortiori[/i] 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]i.e.[/i] 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 [i]parser[/i] 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 :? …