Le Thu, 9 Dec 2010 01:39:33 -0800,
Ian Wilson <[email protected]> a écrit :
> Is work still being done on this ? I have some ideas and I prototyped
> some code.
>
> Would it be acceptable to change this case from:
>
> search: lang: fr_FR en_US
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> search: lang: fr_FR, en_US
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> I have added a comma between values so that lists of values can be
> distinguished from implicit search against rec_name. I think this
> will make it easier for the user to enter searches otherwise implicit
> search against rec_name must be done strictly before any of these
> types of searches. Also I think this would make the implementation
> less complicated.
>
> I think the user will have to quote anything that contains spaces for
> both field names or field values.
> field:value other field: other value
>
> So this must be like this:
> field:value 'other field': 'other value'
>
> -Ian
Hi,
I made some progress on this front: I dropped the idea of using
pyparsing and similar bns-inspired libraries, they are too difficult to
use in this case. After some search I discovered top-down parsing[1],
which is a simple algorithm, easy to tweak and it gives good results.
To answer some of your questions:
- I also think it's better to put comma for the right members of an IN
clause. Without them it's impossible to understand stuffs like :
Name: Julian Paul Assange Eric Daniel Pierre Cantona
While
Name: Julian Paul Assange, Eric Daniel Pierre Cantona
is far more clear (example inspired by Google news). Comma may not be
necessary when we know all the possible values like:
State: Open Close
But I'm in favor of considering the comma mandatory for 'in' clause,
even with well-known values.
- Quotes should be optional, for example:
Name: John Doe Company:Acme
is understandable. But,
King: Henry the First Name:Alfred
(let's say we have a table with a field King, a field Name and a
field First Name) in this case quotes are needed around "Henry
the First" or around "First name" to remove all ambiguity.
In my implementation I favor the longest match on field name (so
implicit "First Name" in this example).
The code is uploaded on codereview[2], but is not complete yet,
currently missing:
- ">" and "<"
- Negation: something like "Name: !John" or "!State: Draft, Confirmed".
- Tweak domain creation wrt to the type of field, for example:
Name: True
should give a different domain that
Active:True
(and maybe "Active: Yes" would be better).
Also:
Parent: Main category
creates something like [('parent', 'ilike', 'Main Category')], which
is not ok.
- Auto-completion only works on fields name, it would be great to also
have it when we know which values are availables (on Bollean and
Selections)
- I also think about stuffs like "Name: Bell*"
- Probably more :)
I propose to keep high-level discussion on this list and remarks about
code details on the codereview.
[1] http://effbot.org/zone/simple-top-down-parsing.htm
[2] http://codereview.appspot.com/3536042 -> if you run it, it will
output for each item of a list of examples: a tree resulting of the
parsing, one or more auto-completion (if possible) and a domain.
> Also I think have in be configurable for this type of thing
> On Fri, Oct 1, 2010 at 12:39 AM, Bertrand Chenal
> <[email protected]>wrote:
>
> > Le Thu, 30 Sep 2010 19:48:11 +0200,
> > Cédric Krier <[email protected]> a écrit :
> >
> > > On 30/09/10 19:31 +0200, Mathias Behrle wrote:
> > > > > > > > 2) Will we lose all those differentiated operators like
> > > > > > > > 'Begins with', 'Is'. etc.?
> > > > > > > >
> > > > > > > > The ideal solution for me would be to have this
> > > > > > > > one-liner-interface (provided it can be done in a
> > > > > > > > sufficient sophisticated way) on top of the form with
> > > > > > > > all other search fields (the well known search
> > > > > > > > interface until now) collapsed. If the search fields
> > > > > > > > could be shown (extended) with a click on an arrow just
> > > > > > > > besides the one-liner-interface all users could have
> > > > > > > > their prefered interface.
> > > > > > >
> > > > > > > The goals is to get rid of the current search view
> > > > > > > because it is not powerfull enough, it takes too much
> > > > > > > place and it is hard to extend it (like having full text
> > > > > > > search).
> > > > > >
> > > > > > The current proposal loses some differentiated operators,
> > > > > > so it is less powerful. It wouldn't take any place if being
> > > > > > collapsed at first sight. Full text search could be only
> > > > > > for the one-liner.
> > > > >
> > > > > There will not be less operators. Every operators in trytond
> > > > > will be available which means there will be more operators.
> > > >
> > > > Of which operators are you talking? Those of
> > > > http://doc.tryton.org/1.6/trytond/doc/topics/domain.html?
> > > > Those don't contain operators like 'start with', 'end with'.
> > >
> > > 'start with' = ilike '...%'
> > > 'end with'= ilike '%...'
> > >
> > > >
> > > > > In fact I readed the code and
> > > > > Bertrand did not follow what we talked. He uses only "ilike"
> > > > > operators but this must be only the default one and operators
> > > > > could be define after the field.
> > > >
> > > > Ok, sounds much better to me, but I still don't know, how you
> > > > would want to name those operators e.g. 'start with' or 'end
> > > > with'. It will be difficult to find intuitive descriptors while
> > > > keeping simplicity for the user. Perhaps a list of possible
> > > > operators could open via completion after inserting a field?
> > >
> > > Most of operators are simple =, <, > etc.
> > > ilike is the default
> > > in will be the default when the value is a list
> > > child_of will need to be defined (but I'm not sure it is useful in
> > > UI).
> >
> > I don't think operators are a difficult problem (at least
> > technically). The biggest obstacle a the moment is to handle
> > correctly the mix of AND/OR and parenthesis while allowing also the
> > user to not put them (I.E. search like "field:value other field:
> > other value").
> >
> >
> >
> > --
> > Bertrand Chenal
> >
> > B2CK SPRL
> > Rue de Rotterdam, 4
> > 4000 Liège
> > Belgium
> > Tel: +32 472 54 46 59
> > Email: [email protected]
> > Website: http://www.b2ck.com/
> >
> > --
> > [email protected] mailing list
> >
>
--
[email protected] mailing list
