All of these config-values are set in the local configs for each database (backend-configfiles config.conf.pl)

$ptr->{tb} defines the table for each config to work on. Usually this table is indexed by the searchengine too. If one wants to index a different table (i.e. a view that contains only specific rows from the real backend-table) then you can set this view/table with

$ptr->{tb_search}

The names of databases are defined per default as the shown names of their corresponding backend-modules as defined in templates.insert.conf : substruct->{abc}->{name}=NAME.

If you need a different name shown in frontend-searchresult than in the backendnavigation, you can set a different name directly in the local searchconfig.

$ptr->{name}="NAME";

For the names of modules please look in the modulename-section

$ptr->{searchconfig}->{short}='SC';

If some fields contain only references to other databases or drop-downfields where the labels are calculated in a special function (and not defined in the fields-configs) you can define a function here that fetches the labels for a field before indexing the field. So even external labels can be indexed.

This function will already exist in almost any case, cause you need the very same function in the backendconfig.

Note that before calling the function, the system will set the variable $ptr->{searchbuild} so the function can return values depending on the fact if its called by the normal backend or by the IndexBuilder. This is very useful, cause most labelgenerating functions for popdowns will limit the number of chars displayed in the popdown.

You can also use this function to put more information in the field that actually is in. With a clever wrapper this function can act as get_val-function as well.

example

$ptr->{searchconfig}->{get_labels}->{myfield}='get_my_labels';

All of these config-values are set in the build_search-tool itself.

$searchconfig

The name and definition of modules (a named set of several databases) are done in

$searchconfig->{overview order}=[['MODULNAME1',[db-short1,db-short2,db-short2,..]],
                                                          ['MODULNAME2',[db-short1,db-short2,db-short2,..]],
                                                        ...];

With this definition the order of the modules in the searchresult and the order of the databases inside a module is also defined.

Note that the MODULNAME is the full name as printed in the searchresult, while the database-names are the shortcuts as defined in shortcuts_of_databases

Note that a database is only printed in the searchoverview if its part of a module here (techdetail: the database is only moved from ->overview to ->overview2 if its listed here. See search1())

Note that changing the Modulname changes the name of the linked icon that is presented in the searchoverview (->suchuebersicht)

The Shortcuts of modules are defined as

$searchconfig->{modules_short}->{SHORT}='db_short1,db_short2,sb_short3';

This is only relevant for the searchterm itself where the module-shortcut is an abrivation for the list of databases.

Note that there is no connection between the moduledefintion for the searchoverview and the shortcutdefinition here. It is - theoretically - possible to add a database inside a module-shortcut, but put it under a complete different module in the searchoverview. So a Database can also be part of more than one modules in the shortcut-definitions. (This is not recommended for the overview !!)

$searchconfig->{url_convert}->{DB-SHORT}=[url,subparameter];

url is relative url beginning with ‘/’ and subparameter is a optional subparamter.

The URL is then created by tt2->url() which gets the url, the subparameter (if any) and the ID of the entry as parameter. (this explains why the subparameter cannot be specified as part of the url)

example:

  url_convert=>{
			   wb=>['/weiterbildung'],
			   wbo=>['/weiterbildung','ort']
                               }