Unified search

Search forms have been implemented several times in Daisy.  We should do some thinking and try to stop all this senseless code duplication :-)

Current proposal for unified search form: (based on forms from fulltext search document include search, image search, ...)

Document name: [____________]
Fulltext query: [____________]
Query type: (o) literal string ( ) lucene query
Collection: collection A (x), collection B (x) [...]
Document type: Simple document type (x) [...]
Search in: [x] name [x] content [x] fields.
Branch: main (x) [...]  Language: default (x) [...] Version: (last / live dropdown)

The collection, document type, branch and language widgets should be designed to take in limited screen real estate and still provide multi-value capabilities:

Possible variations (which may be relevant in some (but not all) contexts):

• Automatically add '%' wildcards when searching the document name field.  Perhaps the document name should be made part of the full text index (or a separate lucene index).
• Only default full-text searching is available
• Document name field is not present, but the search word is automatically put in a separate where clause:  "... or documentName like '%word%' ... ".
• Fulltext field does not make any sense when e.g. searching for images

Operating modes

The search form and search results can be on their own page or can be part of an other page.
The way search results are displayed varies: e.g. simple full-text search or search with preview pane.

Defaults, initial field values, presets

The default values depend on the context where the search form is used:

• when browsing for images with preview pane, we typically only want documentType = 'Image'
• when browsing for documents with preview pane, we typically want documentType='SimpleDocument', but other, user-defined document types can make sense.

Presets: the search forms should have presets, which determine the initial field values.  E.g. a preset for 'Image' should start with documentType='Image'.  Options that make sense in these presets:

• Preselecting collections (none, one particular or multiple ones) -- e.g. start with site-specific
• Preselecting document types -- e.g. start with documentType='Image'

A preset may also contain configuration information for the form, e.g. some widgets should not be shown, some widgets should not be modifiable (UI wise - it makes little sense to check this on the wiki side).
Daisy should come with built-in presets (for images, navigation documents, documents-with-searchable text, ...) and these presets should be user-configurable. e.g. when adding Image-like documents, make sure that the image search form includes these).  These presets should be site-specific.
This can be taken one step further: Provide javascript hooks for form initialization, page load, on field changes, on submit (?)...

The form part and the result part should be separate pipelines, but with a fixed contract w.r.t. html element id's, css class names, js hooks,... so layouts can be reused.

Translation management search

Possibly the TM search form is too specific and should be seen as a separate case:

• For the 'overview' query, the Collections field not present (because variants can be in different collections and we need all variants for the query to give a be correct result)
• It adds a 'reference variant language' and 'reference variant version' choice (but not for all queries)

Fields