|
A) First, you have the input field "Search for:": This is just for general = item-wide string search, can not be used for "search title", for "search item notes", or any other specific field search.
B) Then, you have buttons Start, Reset, Copy, Quick<,
B2) and to its right, there is room for a second input field, albeit not as large as the "Search for:" field.
C) The "list", with and/or (except for the very first row/element), Item/Attribute, Not-toggle, Comparison, and Value fields.
In here, the "Comparison" field is filled by a drop-down menu which just offer those elements / menu entries which make sense for the respective "Item/Attribute" selection, e.g. "Comparison: contains keywords" is present for "Item/Attribute: Item", and others, but not also for "Item/Attribute: Access Count" (since "contains keywords" would not make sens for that); on the other hand, "Comparison: less than" is available for "Item/Attribute: Access Count", but not for "Item/Attribute: Item" - and so on; when "Item/Attribute: Has Children" though, the "Comparison" drop-down just offers "exists" and "equals", and the "Value" column in the list doesn't allow user (string or number) input, but again provides a drop-down, for "yes/no" here.
Thus, it becomes evident that for adding an additional entry "Individual" (or similarly worded) to many (but not all of the) "Comparison" drop-down menus, would be easy, since that additional entry would apply to any "Comparison" drop-down even today, an entry inviting to enter either a string ("contains keywords") or a number ("greater than", etc) is present.
The drop-down "Individual" choice by the user would then automatically fill the "Value" field of that "list" row with a fixed "Individual", not allowing for user input, and if the user wanted to change that, and enter a manual value here, they would have to select another "Comparison" drop-down entry, making available the "Value" field available for manual input again.
Upon "Start" (by enter, or pressing the button), the code would check if there are more than just one "Individual" entries in the list B), and if there are, instead of triggering the search, it would ask the user to change those "Individual" rows to fixed ones (i.e. with a real value within the row's "Value" field, instead of invariant "Individual");
if there is only just one such row though, the code would retrieve the content of field B2) IF there is one, and quickly check if the format applies: just a number if the "Individual" row asks for number input, and any string if that row asks for string input; if there is a string for a number input row, the code would give an error message, along the lines of, "'Individual' input can't be a string here; enter a number, or change 'Item/Attribute' or 'Comparison'";
if there is (residual) input in B2), but no "Individual" row, the sql select is constructed without the B2) string;
if there is an "Individual" row, but no data in B2), then, similarly, the sql select is constructed without the "Individual" row condition.
- My example above shows it very clearly: Really "individual" searches have currently to be made by constructing the search within C), not by combining A) (since A doesn't allow but for too general search scope: the whole item, and for too few logic combinations: no grouping / parentheses allowed in A) with C), and that means often, the user must enter even the main search string of such compound searches within C (where it's cumbersome), instead of entering them in A).
- It might be of some interest, as an alternative to the above, to add the and/or even to C's first row, and then (instead of treating A) and C) as "A AND C" (block-wise)), to imply a "group" just between A) and the very first rows in C) while they are NOT indented, so
A) this
C)
and that
or other
___or these
___and those
would not be translated anymore to
(this) AND ((that or other) OR (these and those))
but to (OR having precedence over AND)
(this and (that or other)) OR (these and those)
In other words, on the logical level, A) would become a part of C), like any row 1, 2, 3... in C) while these rows are not indented.
As said above though, this alternative (avoiding B2) would not resolve the problem of A)'s too global scope, making e.g. individual title:search-string search impossible: the values for string-in-title search would again have to be entered in C), contrary to the first alternative, with B2):
In C), the user would select, for title-search, "Individual", and would then enter the individual value for each new title-search into B2); ditto for any other string or numeric attribute.
That way, the user could create several schema "advanced searches", for different search situations, BUT then enter the individual search string within B2).
Or then, they could enter it in A) IF A)'s functionality was greatly enhanced, allowing for input like
title:search-string notes:search-string,
the code then resolving such keyword:string combinations into the respective column search elements: Such compound searches within the same input field would be a first step to allowing parentheses in there, and would indeed, at some time, make C), the "list", redundant insofar as the "power user" was concerned.
Obviously, B2) is, code-wise and for the user, the simplest solution to the problem; the current "A AND C" (even with an added toggle for "A OR C") though, logically separates the "main search term" from the rest of the conditions, whilst - as shown above - more elaborate compound searches ask for more intimate integration of that "main search term" into other conditions:
My suggested solution, B2) (which, as A does, should also allow for AND and for OR), its value being retrieved by an "Individual" "value" marker in any C) row (as long as it is the only one of its kind), provides that: easy enter and change of the main search term(s), AND permitting that this "string condition" can be placed anywhere in the "select" code.
|