12 Oct
2003
12 Oct
'03
7:49 a.m.
On Sat 11 Oct 2003, Ivor Williams <ivor.williams(a)tiscali.co.uk> wrote:
What I had in mind was a common search cgi script,
which could be passed a
single text string, or could be passed a form with multiple fields in it,
corresponding to the "advanced" search. Either way, it's the same cgi
script being invoked.
Yes.
In fact, it's not AND or OR by default, but a
phrase search. In this case
looking for "sausages oysters", which doesn't make much sense.
I think I'm going to have to have another look at the code when I've
not just got up, because I can't see why this is. Can someone explain
it to me?
I'm wondering what level of commenting you need,
as I didn't think that
the grammar was _that_ difficult to understand - apologies.
The issue is not so much "a search is a list followed by an eostring,
a list is a set of combys separated by '|'", "a comby is a set of
terms separated by '&'" - which I agree is fairly clear once you've
read the Parse::RecDescent perldoc - but the thinking behind the way
the tree is built up. You need to say *why* you're doing what you're
doing.
Anyway, here is an alternative grammar which is a
drop-in replacement,
which does a google style AND by default, and gives you AND if
you separate the words with commas. Phrase search is still available, by
passing a string bounded by "".
Thanks - can you write some tests for this? Don't worry if you can't,
it'll just mean a short delay while I find time to do it.
Kake