Hi,
Am Donnerstag, den 11.02.2010, 21:03 +0100 schrieb Cédric Krier:
> Hi,
> We know all that the current search interface is not perfect. It is easy for
> simple query but not for complex one and the GUI takes a lot of space (even
> without the advanced).
Yes, thats true. But on the other hand the actual implementation is well known
by the users. So changing the ui in this place should be elaborate.
> So we have thought about improving it. Here is some ideas and goals.
> We think that users have their biggest experience in searching through the
> Google webpage. Users know how it works and it is simple.
Web search engines are widely used and known. Thats true. But they
provide all the way full text search functionality of documents. And
searching full-text is always more easy then searching in structured
data.
> So we could apply the same mechanism to the Tryton search by having only one
> long text entry. But we need some specific stuff like being able to specify
> on which field the search must be done etc.
> Here is some examples on how the syntax could be:
> By default search is on rec_name
First improvement: For me the default search should be full text in all
fields indicated by select="1" of a model.
> search: Holmes
> domain: [('rec_name', 'ilike', '%Holmes%')]
>
> By default many value are linked by AND
> search: Holmes Watson
> domain: ['AND',
> ('rec_name', 'ilike', '%Holmes%'),
> ('rec_name', 'ilike', '%Watson%'),
> ]
>
> We can use OR operator
> search: Holmes OR Watson
> domain: ['OR',
> ('rec_name', 'ilike', '%Holmes%'),
> ('rec_name', 'ilike', '%Watson%'),
> ]
>
> Quote to group words
> search: "Sherlock Holmes"
> domain: [('rec_name', 'ilike', '%Sherlock Holmes%')]
>
> Append operator to use it
> search: ="Sherlock Holmes"
> domain: [('rec_name', '=', 'Sherlock Holmes')]
So far so good. The above examples are widely standard imho
and easy to learn for newbies.
> Use field name (label) to search on other fields
> search: Code: 23
> domain: [('code', 'ilike', '%23%')]
Here it starts to get complicated. When we need to
explicitly state the fields to search it is getting
confusing and hard to maintain, if we have three or
more fields.
For a geek expert search your suggestions are quite good.
A user defined search which can be used without knowing
the exact syntax could be a simple domain builder like this*:
[ name | v ] [_______________] ( ) AND ( ) OR
|--------+
| name |
| code |
| amount |
L________|
* On the left selection you choose the model field.
* In the middle entry you put your search criteria
including all the functionalities you mentioned.
The middle entry can be a different widget for different
field types, like selection, list, float, date...
* Check an AND or OR radio button on the right side,
generates a new search line, like this:
[ name | v ] [Holmes_________] (o) AND ( ) OR [ DELETE ]
[ code | v ] [01234__________] ( ) AND ( ) OR [ DELETE ]
Using the radio buttons build a domain as you describe below with
parenthesis.
* When there is more then one line, a DELETE button appears
on all lines. When pressed, the appropriate line will be
deleted and the following lines move one line up, to fill
the gap.
* Even inline 'and' and 'or' are possible:
[ name | v ] [Holmes or Watson__] ( ) AND ( ) OR
> Selection fields are splitted into list
> search: Language: Français English
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
Here I would suggest multi selection with modifier shift for
a range and ctrl for single entries.
> Field name must be case insensitive
> search: language: Français English
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> We can use internal field name
> search: lang: Français English
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> We can use internal values
> search: lang: fr_FR en_US
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> We can compose field search with by default AND
> search: Name: Holmes Language: English
> domain: [('name', 'ilike', '%Holmes%'), ('lang', '=', 'en_US')]
>
> We can compose field search with OR
> search: Name: Holmes OR Language: English
> domain: ['OR', ('name', 'ilike', '%Holmes%'), ('lang', '=', 'en_US')]
>
> But also have many values when composiing
> search: Name: Holmes Watson Language: Français English
> domain: ['AND',
> ['AND',
> ('name', 'ilike', '%Holmes%'),
> ('name', 'ilike', '%Watson%'),
> ],
> ('lang', 'in', ('fr_FR', 'en_US')),
> ]
>
> User can also force how the wildcard are put
> search: Name: Holmes*
> domain: [('name', 'ilike', 'Holmes%')]
>
> Parenthesis could be used
> search: (Name: Holmes AND lang: Français) OR Name: Watson
> domain: ['OR',
> ['AND',
> ('name', 'ilike', '%Holmes%'),
> ('lang', '=', 'fr_FR'),
> ],
> ('name', 'ilike', '%Watson%'),
> ]
>
> Searching on amount
> search: Payable: 1000
> domain: [('payable', '=', 1000)]
>
> search: Payable: >1000
> domain: [('payable', '>', 1000)]
>
> search: Payable: 500..1000
> domain: ['AND', ('payable', '>', 500), ('payable', '<', 1000)]
>
> And idem for dates
>
> For boolean:
> search: Active: false
> domain: [('active', '=', False)]
For one2many and many2many I suggest a mapping of the related fields. So
we can search for specific addresses on party model.
> Of course to be very ergonomic, the text entry will need autocompletion on
> field names, validation of dates and numbers etc.
This all sounds very great. And I am sure I will use the new search
language every day. Users with a lesser affinity for 'programming' their
search domains will see a restriction by a singular entry box for
searches. This gap can be reduced with a domain composer and with a full
text search I suggested above.
For me all ideas having their benefit and weak. But all together, a
standard full text search with only one entry and an advanced search
with a field-wise domain-composer we can serve all the needs together.
Cheers Udo
(*) ASCII-arts are rendered readable with a monospace font.
--
[email protected] mailing list
