Once a search has been done, there needs to be a way of presenting the
output. By default, the SpecialPage search is used -- it is set to results in the distribution demo -- but any number of search pages can be specified
by passing the value in the search form, specified in the variable mv_search_page.
On the search page, some special MiniVend tags are used to format the otherwise standard
HTML. Each of the iterative tags is applied to every code returned from the search -- this is normally the product code, but could be a key to any of the arbitrary databases. The value placed by the
[item-code] tag is set to the first field returned from the search.
The set of tags for [item-list] are available, with the exception of tags like [item-modifier], [modifier-name], [item-accessories], and others that access shopping-cart specific elements. Thse include:
[if-item-data table column] [/if-item-data]
[if-item-field column] [/if-item-field]
[item-code]
[item-data table column]
[item-discount]
[item-field column]
[item-price quantity* noformat*]
In fact, any of the MiniVend database access tags can be used, allowing you to pull data from any of the fields in any of your predefined databases. Along with the MiniVend conditional tags, very complex pages can be built for each individual item returned in the search.
Placed inside the search list. Causes sorting of the search return based on the passed options. The fields that are there to sort are set by mv_return_fields.
The field options passed in either numeric or field name form. If they are field numbers, they are numbered as sent to the search list in the order specified by mv_return_fields, starting from 0 and proceeding upwards. If column names, they are as found in the first record of the searched file (by default the ASCII source for the product database), except for the key or first field. followed by a required colon (:) and the options, if any.
Accepts none, any, or combinations of the flags:
f case-insensitive sort (folded) (mutually exclusive of n) n numeric order (mutually exclusive of f) r reverse sort
The <options> are a field number and an optional flag or flags, in a similar fashion to the Unix sort command, and are interpolated for form values before being used. As an example, if you set up the following fields on your search form:
<INPUT TYPE="hidden" NAME="mv_return_fields" VALUE="0,title,artist,price"> <INPUT TYPE="radio" NAME="the_sort_field" VALUE="title"> Sort by Title <INPUT TYPE="radio" NAME="the_sort_field" VALUE="artist"> Sort by Artist <INPUT TYPE="radio" NAME="the_sort_option" VALUE=""> Forward sort <INPUT TYPE="radio" NAME="the_sort_option" VALUE="r"> Reverse sort NOTE: The 0 refers to the database code/key used for [item-code]
This would combine with the following search result page fragment to sort by either title or artist.
[search-list]
[sort]
[value the_sort_field]:[value the_sort_option]
[/sort]
<B>[item-field title]</B>, by [item-field artist]<BR>
[/search-list]
The [value...] lines will end up looking like artist:r or title:. This could also be specified with 2r or 1.
PERFORMANCE TIP: on heavily trafficked systems, it will pay to use only column numbers rather than named fields, as it reduces processing and may obviate an access to the searched file to find the field names.
[search-list][/search-list].
Along with the companion [/item-change marker], surrounds a region which should only be output when a field (or other
repeating value) changes its value. This allows indented lists similar to
database reports to be easily formatted. The repeating value must be a tag
interpolated in the search process, such as [item-field field] or [item-data database field].
Of course, this will only work as you expect when the search results are properly sorted.
The marker field is mandatory, and is also arbitrary, meaning that you can select any
marker you wish as long as it matches the marker associated with [/item-change marker]. The value to be tested is contained within a [condition]value[/condition] tag pair. The [item-change marker] tag also processes an [else] [/else] pair for output when the value does not change. The tags may be nested as
long as the markers are different.
Here is a simple example for a search list that has a field category and
subcategory associated with each item:
<TABLE>
<TR><TH>Category</TH><TH>Subcategory</TH><TH>Product</TH></TR>
[search-list]
<TR>
<TD>
[item-change cat]
[condition][item-field category][/condition]
[item-field category]
[else]
[/else]
[/item-change cat]
</TD>
<TD>
[item-change subcat]
[condition][item-field subcategory][/condition]
[item-field subcategory]
[else]
[/else]
[/item-change subcat]
</TD>
<TD> [item-field name] </TD>
[/search-list]
</TABLE>
The above should put out a table that only shows the category and
subcategory once, while showing the name for every product. (The
will prevent blanked table cells if you use a border.)
[item-change marker].
[more-list] and [/more-list]
element pair.
[more_list] and [/more_list] elements is stripped.
Use in conjunction with the [more] element to place pointers to additional pages of matches.
If the optional arguments next_img, prev_img, and/or page_img
are present, they represent image files that will be inserted instead of
the standard 'Next', 'Previous', and page number. If prev_img
is none, then no previous link will be output. If page_img is
none, then no links to pages of matches will be output. These are URLs, are
substituted for with ImageDir and friends, and will be encased in
IMG tags. Lastly, border is the border number to put.
In addition, if page_img is used, it will be passed an argument of the digit that is to be
represented. This would allow an image generator program to be used,
generating page numbers on the fly. The border
and border_selected values are integers indicating the border that should be put around images
in the page_img selection. The <border_selected> is used for the current page if set.
As an example, if you use [more-list next.gif prev.gif page_num.cgi], the following will be the anchors:
Previous <IMG SRC="prev.gif"> Page 1 <IMG SRC="/cgi-bin/page_num.cgi?1"> Page 2 <IMG SRC="/cgi-bin/page_num.cgi?2"> Next <IMG SRC="next.gif">
If you wish to set custom text for the ``Previous'' and ``Next'' usually
used, then you can define the next_img, prev_img, and page_img with
[next-anchor][/next-anchor], [prev-anchor][/prev-anchor] and
[page-anchor][/page-anchor]. The string
$PAGE$ will be replaced with the page number in the
latter. The same example:
[more-list 0 0 0]
[next-anchor] Forward [/next-anchor]
[prev-anchor] Back [/prev-anchor]
[page-anchor] Page $PAGE$ [/page-anchor]
[more]
[/more-list]
will display U<Forward Page 1 Page 2 Back> for 2 pages.
As shown, you must pass a 0 for the arguments of each to tell MiniVend to look for the assignments.
If you have many pages of matches and don't wish to have all displayed at
once, you can set [decade-next][/decade-next]
and [decade-prev][/decade-prev]. If you set them empty, a search with 31 pages will display pages 21-30
like
Previous 1 2 3 4 5 6 7 8 9 10 [more>>] Next
and pages 11-20 like:
Previous [<<more] 11 12 13 14 15 16 17 18 19 20 [more>>] Next
If you set them to [decade-next](higher)[/decade-next] and
[decade-prev](lower)[/decade-prev] you will see:
Previous (lower) 11 12 13 14 15 16 17 18 19 20 (higher) Next
Of course image-based anchors can be used as well.
[more-list].
Previous 1 2 3 4 5 6 Next
The current page will not be a hyperlink. Every time the new link is
pressed, the list is re-built to correspond to the current page. If there
is no Next or Previous page, that link will not be shown.
See the fr_resul.html or search.html files for examples. Make sure you insert this item between a [more-list] and [/more-list] element pair.