Well I wrote a small implementation with pyparsing because I had used
booleano before for something similar. It requires stricter quoting and
commas though to be sensible. I will send it later after I clean it up a
bit and maybe it will be helpful.
I only parsed the structure though and did not consider anything with
regards to tryton yet. I think it would be easier that way.
Is implicit search of rec-name still allowed? If so how do you know Paul and
Assange are not implicit searches against rec-name? It seems difficult to
explain to user that implicit searches only work before any fields are
specified and after that they become part of the last field specified.
Name: Julian Paul Assange
I think this should be quoted if you want to search for the combined string
or separate by commas if you want to search by each separate word.
Also I think field should determine the default operator and possible
operators.
It seems that autocomplete will be hard unless we move the : to the front of
the field name. How will you know to auto complete a field instead of some
sort of value? Won't auto complete for names coming up when you are
entering values be intrusive?
Another thing, it might be better to use '-' when field name have spaces,
such as first-name:ian instead of trying to figure out if first name: is one
field or requiring quoting such as 'first name': . Google seems to use _
for that in google news when I switch between advanced search and regular
search.
Also overall I think things will have to be more complicated than google
search because a business database has much richer content and users want to
access it rather than just free text. That is why I think stricter quoting
would be more acceptable.
-Ian
On Thu, Dec 9, 2010 at 12:29 PM, Bertrand Chenal
<bertrand.che...@b2ck.com>wrote:
> Le Thu, 9 Dec 2010 01:39:33 -0800,
> Ian Wilson <vengfulsquir...@gmail.com> 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
> > <bertrand.che...@b2ck.com>wrote:
> >
> > > Le Thu, 30 Sep 2010 19:48:11 +0200,
> > > Cédric Krier <cedric.kr...@b2ck.com> 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: bertrand.che...@b2ck.com
> > > Website: http://www.b2ck.com/
> > >
> > > --
> > > tryton-dev@googlegroups.com mailing list
> > >
> >
>
> --
> tryton-dev@googlegroups.com mailing list
>
--
tryton-dev@googlegroups.com mailing list
