re: [pilot-db-list] Plans for filters?

[Nathan K. <na...@va...>]

Greg Alt <ga...@es...> writes:
> 
> What I envision is something like the different list views, where you can
> create different filters each with a different name, and then you can
> select one to perform that filter.  The default would be an empty filter
> that just let's everything through.
> 
> When editing a filter, you would be presented with a screen very similar
> to the sort screen.  Something like this:
> 
>     op cs Field value     Field
> *   <  x  ____________  * field name
> 
> 
> Clicking on the first * would give you a pulldown letting you insert
> another filter line.  Clicking on the op field would give you a pulldown
> letting you choose a filter operation (<, >, =, <=, >=).  The field name
> would be chosen just as for Sorting, and the field value is the value to
> perform the operation to filter against (so, <= for a date field would
> select all records with the date field showing a date before or on the
> specified date).  

A few months ago, I spent some time thinking about how filters could
be done, and came up with essentially the same approach.  Then I got
distracted by trying to fix GDB/prctools and didn't come back to it.
But somewhere I've got a lot of scribbled scrap papers with 'screen
shots' virtually identical to this.  Which is to say, I like it.

I was picturing infix notation instead of prefix: [FIELD op (value)]
instead of [op (value) FIELD].  Did you grow up with using HP's
reverse-polish-notation calculators, by any chance? <smile>

Inserting fields seems good.  I was thinking of just having one button
to add a new line at the end, but insertion might be more useful.
Being able to delete lines might be good, too.

I feel that sorting and filtering should be combined---at least so
that when one searches by a field the search results are displayed
sorted by that field.  Perhaps this requires an 'reverse' checkbox.

> Then, when you select that filter, each filter operation is essentially
> ANDed together.

Strong agreement.  Small, simple and intuitive.  Support for
generalized Boolean queries might be nice, but could be added later.

> For now, filters could be selected the same way list views are now (go to
> the display menu option and have pulldowns for both view and filter).
> Later, support could be added for named reports that specify both a view
> and a filter -- then you just click the report you want and it shows it
> with one click.

I'd wonder if there is room for this at the bottom of the View screen,
replacing some of what is already there.  One can tell at a glance
what View one has; I think one should be able to see what Filter is in
effect as well.  I also think that easy filtering could supplant Find.

I agree with named reports, and think this could be handled under the
existing Views.  Each View could have a default filter, which could
then be changed from within the View.  Default filter is 'none',
sorted by column order.  Multiple views with identical fields but
different filters could account for the features of named reports.

> Any comments, improvements, alternatives?

Sounds great to me!

--nate