Html Endpoint

Introduction

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

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?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
  1. 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:

OptionValuesExplanation
collectioncollection IDThis 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.
formsimple, advanced, otherThe 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.
queryvalid queryThe query terms to be processed. See the page on simple searches for details on what makes a valid query.
sAdditional query expressionAdditional 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.
clivecollection IDThis 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
gscope1comma separated list of gscope numbersThis 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_Xvalid query termAdds 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 termDate-based metadata search fields.
meta_X_year, meta_X_month, meta_X_dayvalid query termDate-based metadata search fields.
profileprofile nameThis option is identical to the 'profile' option specified in the Query Processor Options.
query_andvalid query termAdds 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_sandvalid query termAdds a compulsory and term to the query to be processed. E.g. selecting query_sand=term adds the term ''
query_truncvalid query termAdds 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_phrasevalid query termAdds 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_proxvalid query termAdds 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_orvalid query termAdds 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_orplusvalid query termAdds 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_orsandvalid query termAdds a compulsory or'ed term to the query to be processed. E.g. selecting query_orsand=term%20word adds the term ''
query_notvalid query termAdds 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.
scopescope stringSimilar 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.

See also

top