Am Freitag, den 12.02.2010, 12:29 +0100 schrieb Cédric Krier: > On 12/02/10 12:32 +0100, Udo Spallek wrote: > > First improvement: For me the default search should be full text in all > > fields indicated by select="1" of a model. > > Why not. But you can not do the same search on different kind of fields with > the same value. Per example string with float, etc. Hmm, but you suggested that the field is a text entry box. So everything in the input is text. Searching for 0.00 can search all float, numeric, char and text fields.
> By the way, using rec_name will extend the default behavior as it is already > done on many2one fields and many2many. > Of course this new syntax could be applied to those fields. > > For one2many and many2many I suggest a mapping of the related fields. So > > we can search for specific addresses on party model. > This is hard because the client don't know necessary the structure of the > relation field. But it could be a futher improvement. ok. > > > 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. > I find "domain composer" too complex, not ergonomic and take too much space. I'm unsure if learning a search grammer is less complex then using a domain composer with good restrictions on input level. The same with the ergonomic reasons: If you like to 'code' your search domain, it is more ergonomic. If not, it is much more ergonomic to use a simple self explanatory domain builder instead of reading documentation to just start a search. Space for the standard search with a domain builder is the same as your proposal. Just a single line. for each AND, OR it is one line more. > I think what you try to achieve with the "domain composer" can be done on a > text entry with a good (smarter) autocompletion. > Here is a scenario: > Typing: n > Screen: > [n| ] > |------- > |Name | > |Number| > |... | > |------| > > Select: Name > Screen: > > [Name: | ] > > Typing: Watson > Screen: > > [Name: Watson | ] > > Typing: c > Screen: > > [Name: Watson c ] > |----| > |Code| > |... | > |----| > Select: Code > Screen: > > [Name: Watson Code: | ] > > Etc. > Autocompletion should work also on operators AND, OR > If a selection field is set: autocompletion must be also filled with selection > values. > And the convertion to domain should work even if missing closing ) Yes, I am sure it can be fault tolerant in some way and with a good auto completion for fields and logical operators. IMHO the biggest issue in your proposal is, that the valid check for field operands will be done after hitting the search button. On input seems everything possible, because everything can be a search string. E.g. what would be the solution for a search like this: '''Comment: and as Watson said loud at the very beginning of the party: Holmes, Reputation is made in a moment: It takes a lifetime to build character.''' In this string are several problems to evaluate, because you can not decide what is search grammer and what is its context. In the actual implementation the check is a restriction on input time, which I find much better, because you need no error messages like: 'A date field must look like dd/mm/yyyy'. Now an input field for a date is: __/__/____ [] with a nifty popup calendar button on the side. Other example is, we can not put the string 'hello world' in a field numeric, because only numbers, minus and a separator are allowed for input. The actual implementation has also a good restriction of operators for the different fields. Not to say that we have named operators like starts with, contain, end with... Will this all be lost? For me all the stuff we have is the half way to a domain composer. > > 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. > Yes but it is harder to maintain I'm not sure if it is harder to maintain, because a lot of concepts from the actual implementation can be reused. > and I find merging the both into one will be > a big improvement. Because it could be used in many places (many2one, > many2many etc). -- [email protected] mailing list
