On 12/02/10 16:03 +0100, Udo Spallek wrote: > 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.
No, you can not search on a float with a string. > > > > 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 you don't see the complexity of a domain builder like you describe. Because once you have AND and OR operator, you must have parenthesis and at this point this become complex (for the code and for the interface). I think we can find a grammar that doesn't need to be learn because of the simplicity and the help of autocompletion etc. > 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 It could have some typing check (like on date and number fields). > 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. You can because we know the name of the fields. So if a string that ends with a ":" matches the name of a field, it is a search on a field. > > 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. We can acheive that. > > 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. I think it is an end way. Most of the search are really simple and so a domain composer will be use very rarely. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpMebHG6vtxh.pgp
Description: PGP signature
