Funnelback logo

Documentation

CATEGORY

Search.html

Introduction

search.html is the main entry point of Funnelback's Modern UI search interface. The Classic UI equivalent is search.cgi.

It has responsibility for:

  • displaying search forms
  • validating and executing queries
  • the formatting and display of search results

Changing the look, feel and general presentation of search results can be achieved through modifying the search form files, and by modifying the parameters that search.html receives (usually from HTML forms).

Processing steps

A simplified set of steps performed by search.html is:

  1. HTTP request for search.html?collection=shakespeare (Optionally &query=juliet).
  2. Run the query if there is one and gather result data from the query processor (PADRE)
  3. Populate a data model containing:
    • The input parameters for the query
    • The response from the query processor, if any
    • Any error raised
  4. Return HTML by merging the data model with the rendered search form (template).

Advanced query string parameters

search.html has its behaviour and the results it presents controlled by the parameters that are given to it by means of the requested URI. Many of these parameters are really query processor options, and hence are documented in the section on Query Processor Options.

The other parameters specific to search.html that are available and their meanings are listed here.

Remarks:

Option Values Explanation
collection collection ID This is the most important parameter as it selects the collection to be searched over. Many aspects of Funnelback's behaviour will be controlled by the collection-specific configuration files. E.g selecting collection=myIntranet will search across the myIntranet collection.
form simple, advanced, other The name of the form file to use as the basis for the search interface. E.g. selecting form=simple will use the simple.ftl (Modern UI) or simple.form (Classic UI) as an interface.
query valid query The query terms to be processed. See the page on simple searches for details on what makes a valid query.
s Additional query expression Additional query terms that will be appended to the value of query. Spelling suggestion won't apply for those terms. This is usually used to send system generated queries, i.e. query terms generated by the search UI and not directly entered by the user.
clive collection ID This option specifies which components of a meta collection to search at query time. Use separate parameters for multiple collections e.g. clive=collection_one&clive=collection_two
gscope1 comma separated list of gscope numbers This option is similar to the 'gscope1' option specified in the Query Processor Options but if specified here, it can simply be a list of gscope numbers that will be treated as being or'ed together, rather than requiring a full reverse Polish expression.
meta_X valid query term Adds a metadata search field to the query to be processed. E.g. selecting meta_X=term adds the term X:term to the query, where 'X' is a valid metadata class (a-z, A-Z, 0-9). This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
meta_X (d, d1, d2, w1, w2, x, y, z) valid query term Date-based metadata search fields.
meta_X_year, meta_X_month, meta_X_day valid query term Date-based metadata search fields.
profile profile name This option is identical to the 'profile' option specified in the Query Processor Options.
query_and valid query term Adds an and term to the query to be processed. E.g. selecting query_and=term adds the term +term to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_sand valid query term Adds a compulsory and term to the query to be processed. E.g. selecting query_sand=term adds the term ''|term'' to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_trunc valid query term Adds a truncated term to the query to be processed. E.g. selecting query_trunc=term adds the term *term* to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_phrase valid query term Adds a phrased term to the query to be processed. E.g. selecting query_phrase=term%20word adds the term "term word" to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_prox valid query term Adds a proximity set of terms to the query to be processed. E.g. selecting query_prox=term%20word adds the term `term word` to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_or valid query term Adds an or'ed set of terms to the query to be processed. E.g. selecting query_or=term%20word adds the term [term word] to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_orplus valid query term Adds an or'ed set of terms to the query to be processed, where the or'ed terms are required to be present in matching documents. E.g. selecting query_orplus=term%20word adds the term +[term word] to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_orsand valid query term Adds a compulsory or'ed term to the query to be processed. E.g. selecting query_orsand=term%20word adds the term ''|[term word]'' to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
query_not valid query term Adds a not term to the query to be processed. E.g. selecting query_not=term adds the term -term to the query. This is mainly used in advanced search forms where the query must be made up from different HTML form entries.
scope scope string Similar to the 'scope' option specified in Query Processor Options but if specified here, multiple 'scope' parameters will be conflated into one parameter.

The Query Processor Options page lists CGI parameters specific to the query processing system, including sorting, stemming and many more.

Additional smeta / squery (System-Generated) parameters

The Modern UI supports smeta_* and squery_ parameters in a similar syntax of the meta_*, query_* parameters above, except for the date related ones.

These parameters will get passed to the query processor as system or technical parameters (as opposite to user entered parameters). They are usually injected programmatically through user interface hook scripts. Parameters passed in this fashion won't go through the Spelling Suggestions or Query Blending systems.

Unsupported parameters

Please find below the parameters from the Classic UI that search.html doesn't support:

Option Values Explanation
cleanhtml 1 The same effect can be achieved in your template by using the <#compress /> FreeMarker directive.
enc character encoding The character encoding will always be UTF-8. If you need to output different encodings, please contact Funnelback support.
oneshot 1 This feature is not available with the Modern UI.
showform true/false This parameter is not available however a similar feature can be achieved in the FreeMarker template itself if needed. The FreeMarker template can check if a showform parameter has been set and display the initial form.
tiers on/off This parameter is not available but a similar effect can be re-implemeted in the FreeMarker template.
bb_tiers on/off This parameter is not available but a similar effect can be re-implemeted in the FreeMarker template.
xml 1 You must use search.xml or search.classic to access the XML version of the search results.
morph, morph_target various This feature is not available with the Modern UI.

See also

top ⇑