HTML endpoint

Introduction

search.html is the main entry point of Funnelback’s Modern UI search interface.

It has responsibility for:

  • displaying search templates

  • 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 template 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?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 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.

These parameters also apply to search.xml and search.json.

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) 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 suggestions won’t be generated for those terms and synonyms and query blending won’t be applied. 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_CLASS*

valid query term

metadata special CGI parameters.

smeta_CLASS*

valid query term

system generated metadata special CGI parameters. See: system query parameters section below.

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. Not supported in document at a time mode (which is the default)

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.

System query parameters

The system query parameter is search query input field that can be used to supply search terms and constraints to a search query that are treated as hidden parameters.

The system query accepts a query specified using Funnelback’s query language operators (the same as in a standard query field) but with the following differences:

  • The system query field is not modified by transformation features such as spelling suggestions and query blending. (Note: stemming is applied to the system query)

  • Values within the system query field are not displayed in the cleaned query (so don’t display on the search interface)

  • Values within the system query field are not displayed in the search analytics

System query parameters should be used for any system generated queries such as cases where Funnelback’s search index is used like a database. This keeps that analytics clean (so it only reports on the queries that the user types) and also avoids synonym/query blending transformations that don’t make sense for a system query.

The system query parameter is accessed via the s and smeta_X_* parameters.

The following table illustrates standard query parameters and their system query equivalents (Note: replace X with the relevant metadata class name):

Standard query parameter System query parameter Example (CGI parameter)

query

s

s=%22julius%20caesar%22%20%2Bcity%3Arome

meta_X

smeta_X

smeta_city=paris

meta_X_and

smeta_X_and

smeta_city_and=london

meta_X_or

smeta_X_or

smeta_city_or=stockholm

meta_X_phrase

smeta_X_phrase

smeta_city_phase=washington%20dc

meta_X_not

smeta_X_not

smeta_city_not=berlin

meta_X_sand

smeta_X_sand

smeta_city_sand=sydney

meta_X_orsand

smeta_X_orsand

smeta_city_orsand=beijing

Setting the system query parameter using a hook script

The system query parameter can be supplied as a CGI parameters (&s=, &smeta_X=) but can also be injected into the data model from a user interface hook script but must be done so by adding to inputParameters.

transaction.question.inputParameters.replaceValues("s", ["VALUE"])