Well, I've quite frequently seen queries in rows of 3 elements: a list box with the columns in your db (or plain english names for them), another list box of operators (=, >, <, >=, <=, contains, etc.), and then a text box for the search value.
At the end of each row, you have a button which will allow the user to add another row to the query. I think where I've seen it used, there's an implied AND between the rows. You run into permutation problems with nesting if you offer an OR option between rows.
HTH--I guess it's stating the obvious, but I thought I'd let you know--this seems a fairly common way of doing things. My company organises its search forms this way. | [reply] |
The question "is this the best approach" is hard to answer
as you don't give any indication what you consider the best.
Best as in "userfriendly", "fast", "most flexible", "easy on
the database server", "maintable"?
As for parsing, one could use Parse::RecDescent. That's very
easy to write a grammar for, but it's not going to be fast.
For a simple AND/OR/NOT language, it's easy to write an LR(1)
or LL(1) grammar, and those can be parsed much faster. You could
use Parse::YAPP, or write a custom parser. You might even want
to do it in C. It depends on what kind of trade-offs you are
going to make between running time and programming time.
Abigail | [reply] |
This is exactly what I've been doing at work for the last six months or so. Granted, it's not perl related (what I do, I mean), but I had to go over the exact same interface questions that you are going through here.
The first thing that I think you should ask yourself is "Who is going to be using this 'Advanced Search'?" I would say go ahead and allow the user to write their own queries if:
- They will know SQL and understand what they're doing
- They will be able to read a paragraph or so of instructions that describe how to use the query grammar you will provide to them
This leaves out most of the web using public, so if that is your intended audience I think you're best off using standard UI widgets that they will have seen before and are comfortable with.
I've had good success with the method you are currently using. It's intuitive enough for most users to comprehend without any instructions and it converts very easily into SQL statements when you need to parse the form.
I think the most important thing here is to get feedback from your users to find out if the Advanced Search capabilities you've offered are getting the job done for them. Maybe just have a small form on your results page that they can check whether or not they found what they were looking for.
~CubicSpline
"No one tosses a Dwarf!" | [reply] |
I agree with Basilides on this one. I think it's important that the users be able to select their search terms themselves, rather than being forced to type them in. That leaves some people unable to use advanced search, even if they know what they want but just do not know how to search for it. | [reply] |
Thanks all I'm defining best as the easiest most intuitive way for the user without restricting the power of the searching. I want to stay away from Javascript for application critical functions so a ui widjet query builder is probably not for me but a good idea anyway. I reckon if I stick to the standards set by google and altavista for complex web searches most people will intuitively know how to use it. Will have first attempt using the module above | [reply] |