The supplied simple/srchform.html
and simple/results.html
pages show example search forms. You can modify them to present the search
in any way you like -- just be careful to use the proper variable names for
passing to MiniVend. It is also necessary that you copy the hidden
variables as-is -- they are required to interpret the request as a search.
NOTE: The following definitions frequently refer to field name and column and column number -- all are the references to the columns of a searched text file as separated by delimiter characters.
The field names can be specified in several ways.
file(s).
(This is defined to be products.txt
in the MiniVend demonstrations.)
Careful if you are using
SQL! If you change your database and don't export it
with [tag export products][/tag]
, you will not find what you want.
Fields can also always be specified by an integer column number, with 0 as the first column.
Set this if you anticipate searching for lots of punctuation characters that might be special characters for Perl -- the characters ()[]\$^ are included.
In the text search, set to the directory from which to base file searches.
File names without leading / characters will be based from there. In the
Glimpse search, passed to Glimpse with the -H
option, and Glimpse will look for its indices there. Default is ProductDir.
If you use an absolute path directory, for security you must enable it in the users session with:
[set /directory/name]1[/set]
This prevents users from setting an arbitrary value and viewing arbitrary files.
This is a multiple parameter. If mv_coordinate is in force, then it should be set as many times as necessary to match the field/searchstring combination. If set only once, it applies to all fields. If set more than once but not as many times as the fields, it will default to off.
If stacked to match the mv_search_field and mv_searchspec variables, and mv_coordinate is set, it will operate only for the corresponding field.
Case sensitivity, substring matching, and negation all work on a field-by field basis according to the following:
If only one instance of the option is set, then it will affect all fields.
If the number of instances of the option is greater than or equal to the number of search specs, all will be used independently. Trailing instances will be ignored.
If more than one instance of the options are set, but fewer than the number of search specifications, the default setting will be used for the trailing unset options.
If a search specification is blank, it will be removed and all case-sensitivity/negation/substring options will be adjusted accordingly.
The order of this and the mv_dict_end variable is significant -- each will overwrite the other.
If this is set to a non-numeric value, an automatic mode is entered which
looks for a dictionary-indexed file that corresponds to the file name plus
.field, where field is what you have set mv_dict_limit to. The actual value of mv_dict_limit is set to -1
. If the file does not exist, then the original file is silently used (this
might not be what you want!). Also, the value of mv_return_fields is set to 1
to correspond to the location of the key in the auto-indexed file.
To illustrate:
<INPUT TYPE=hidden NAME=mv_dict_limit VALUE=category> <INPUT TYPE=hidden NAME=mv_search_file VALUE="products.txt">
is equal to:
<INPUT TYPE=hidden NAME=mv_dict_limit VALUE="-1"> <INPUT TYPE=hidden NAME=mv_search_file VALUE="products.txt.category"> <INPUT TYPE=hidden NAME=mv_return_fields VALUE="1">
The real utility would be in a form construct like
Search for <SELECT NAME=mv_dict_limit> <OPTION> author <OPTION> title </SELECT> beginning with <INPUT NAME=mv_dictlook>
which would allow automatic binary search file selection.
Combined with the INDEX
attribute to the Database directive, this allows fast binary search qualification combined with
regular
mv_searchspec text searches.
Defines the field names for the file being searched. This guarantees that they will be available, and prevents a disk access if using named fields on a search file (that is not the product database ASCII source, where field names are already known). This must be exactly correct, or it will result in anomalous search operation. Usually passed in a hidden field or search profile as a comma-separated list.
NOTE: You should use this on the product database only
if you plan on both pre-sorting with mv_sort_field and then post-sorting
with [sort]field:opt[/sort]
.
[more-list]
is present. Can be implemented as a scrolling list
(INPUT
TYPE=SELECT) or radiobox
(INPUT
TYPE=RADIO) field.
If stacked to match the mv_search_field and mv_searchspec variables, and mv_coordinate is set, it will operate only for the corresponding field.
mv_last
, is defined, it will prevent the scanning of the form input for further
search modifications. The values of mv_searchspec and
mv_dict_look are always scanned, so you can specify this to do the equivalent of setting
multiple checkboxes or radioboxes with one click, while still reading the
search input text.
field(s)
to be searched, specified either by column name
or by column number.
If the number of instances matches the number of fields specified in the mv_searchspec variable, and mv_coordinate is set to true, each search field (in order specified on the form) will be matched with each search spec (again in that order).
file(s)
to be
scanned for a match. The default, if not set, is to scan the default
ProductFiles (i.e. products.txt). If set multiple times in a form (for a
text search), will cause a search all the files. One file name per
instance.
In the Glimpse search, follows the Glimpse wildcard-based file name matching scheme. Use with caution and a liberal dose of the Glimpse man page.
The user can place quotes around words to specify that they match as a string. To enable this by default, use the mv_exact_match variable.
If mv_dict_look has a value, and mv_searchspec does not, then mv_searchspec will be set to the value of mv_dict_look.
If the number of instances matches the number of fields specified in the mv_search_field variable, and mv_coordinate is set to true, each search field (in order specified on the form) will be matched with each search spec (again in that order).
If set to sql, formulates an SQL select statement to return the search list.
If set to db, iterates over every row of the database (not the associated text source file).
If set to text, selects the text-based search.
Defaults to text if Glimpse is not defined, to Glimpse if it is. This can allow use of both search types if that is desirable -- for instance, searching for very common strings is better done by the text-based search. An example might be searching for categories of items instead of individual items.
field(s)
the search is to be sorted on, specified in
one of two ways. If the file(s)
to be searched have a header
line (the first line) that contains delimiter-separated field names, it can
be specified by field name. If can also be specified by column number (the
code or key is specified with a value of 0, for both types). These can be
stacked, if coming from a form, or placed in a single specification
separated by commas.
NOTE FOR ADVANCED USERS: If specifying a sort for the product database, mv_field_names must be specified if you will be doing a fieldname-addressed post-sort.
r
, n
, and f -- for reverse, numeric, and case-insensitive respectively. These can be
stacked, if coming from a form, or placed in a single specification
separated by commas. The stacked options will be applied to the sort fields
as they are defined, presuming those are stacked.
If stacked to match the mv_search_field and mv_searchspec variables, and mv_coordinate is set, it will operate only for the corresponding field.