Re: Filters as views (ISSUE-45)

>> We're making things too complicated.
> 
> I fully agree. I think we need to take a step back and look at this with
> fresh eyes. I would like this to be closer to HTML forms than to S(PAR)QL
> queries.

Exactly.

Perhaps we still need to draft a couple of alternative directions.
Just to see if they might be easier.

>> A minimal set of symbols includes for me
>> at least the possibility to describe
>> how a form creates a view from a collection
>> for basic combinators such as AND and EQUALS.
> 
> Are you sure the EQUALS is enough?
> In a lot of cases the AND can be transformed into an OR by issuing multiple
> separate queries but the comparison operator can't be changed with such a trick.

EQUALS is not enough for everything; but it is a good default.
The mechanism should be extensible (for instance, freeTextQuery).

>> we should make that mechanism extensible
>> to support other ways of defining views in the future.
>> Otherwise, it's again a one-off.
> 
> That's the point I'm struggling most with. Keeping this extensible (without
> having to change most of the concepts) introduces a lot of complexity. I
> haven't found an elegant way to tame that yet. Do you have any ideas in that
> regard?

A generic notion of expressions should be sufficient.
The core could define a couple of basic operators (AND / EQUALS / …);
other specifications might define more complex expressions.

Best,

Ruben

Received on Wednesday, 24 February 2016 08:46:14 UTC