... | ... | @@ -38,14 +38,14 @@ The configuration file mainly consists of these groups: |
|
|
* prefillValuesFromExternalSources
|
|
|
|
|
|
#### `inputForms`
|
|
|
This is an array with objects that describe forms used to create and maintain authorities, e.g. _Person_s or _Place_s. Each has an array of inputs specifying which RDF-property should be made available for entry.
|
|
|
This is an array with objects that describe forms used to create and maintain authorities, e.g. _Person_ or _Place_. Each has an array of inputs specifying which RDF-property should be made available for entry.
|
|
|
#### `tabs`
|
|
|
This is an array og objects each describing a tab in the workflow, with attributes like tab label but most important which type of resource the fields in the tab adresses. The application can at any time handle one resource of each type, so all tabs with the same `rdfType`, e.g. `Work` targets the same resource.
|
|
|
|
|
|
Inside each tab there is an array of `inputs`, each consisting of an object describing how a particular predicate from ontology is handled. Note that not all inputs are connected to a predicate, some special cases are used for search e.g. for retrieving existing work to be edited or for external data lookup by e.g. ISBN. Even if these are used only once each, they are configured and not hard coded, again following the principle from earlier. Input fields may fetch label from the ontology, or it can be overridden in the config file. They may also be shown only when other inputs have certain values, e.g. only show the `EAN` field when `mediaType` is film or musical recording.
|
|
|
|
|
|
##### Input types
|
|
|
Usually, the type of an input is inferred from the type of the corresponding predicate from the ontology e.g. string, number etc. However, for inputs linking to other resource, one has to add `type: 'searchable-with-result-in-side-panel'` indicating that the field will either show the name of a linked resource (e.g. an author's name) or be used as a search field to look up linkable resources. When searching, a popup list appears next to the field, where one can select one of existing resources, og create a new one.
|
|
|
Usually, the type of an input is inferred from the type of the corresponding predicate from the ontology e.g. string, number etc. However, for inputs linking to other resource, one has to add `type: 'searchable-with-result-in-side-panel'` indicating that the field will either show the name of a linked resource (e.g. an author's name) or be used as a search field to look up linkable resources. When searching, a popup list appears next to the field, where one can select one of existing resources, og create a new one. The property `nameProperties`is an array listing predicates in short form (i.e. only the fragment part of predicate's uri) by which the displayed value should be comprised of. Possible values here are `prefLabel`, `name`etc.
|
|
|
|
|
|
Another important input type is dropdown list with predefined values, such as language. The actual values are extracted from the ontology.
|
|
|
|
... | ... | @@ -56,7 +56,11 @@ An important property of inputs are `widgetOptions` structure which holds variou |
|
|
Some inputs are nested, and therefore has both their own predicate linked to by parent resource and an array of `subInputs`. These target blank nodes, which are handled as groups of data that are either all saved or none. An example of such objects are `Contribution`s which have both a person and a role, e.g. author linking a _Work_ to a _Person_. To allow contributions to be linked to either from Work or Publication, compound inputs may have multiple types as domain, e.g. both _Work_ and _Publication_. Radio buttons for selecting source for the link to _Contribution_ are therefore rendered when compound input has more than one `subjects`.
|
|
|
|
|
|
#### `authorityMainintenance`
|
|
|
Configures input search fields to be displayed on the authority maintenance page. For each editable authority resource type, one can configure search parameters in terms of which elasticsearch index type to use, and if present, a `widgetOptions` structure describing how the resource should ne handlet in terms of which form or which template to be used. Simple resource types, such as _Person_ or _Place, may be edited by the popup input forms most suited (from `inputForms` above), while the more complex, such as _Work_ and _Publication_ should be opened with the workflow template.
|
|
|
Configures input search fields to be displayed on the authority maintenance tab of the menu page. For each editable authority resource type, one can configure search parameters in terms of which elasticsearch index type to use, and if present, a `widgetOptions` structure describing how the resource should ne handlet, that is, which form or which template to be used. Simple resource types, such as _Person_ or _Place, may be edited by the popup input forms most suited (from `inputForms` above), while the more complex, such as _Work_ and _Publication_ should be opened with the workflow template.
|
|
|
|
|
|
#### `search`
|
|
|
Configures
|
|
|
|
|
|
### State model
|
|
|
### Partials
|
|
|
### Decorators
|
... | ... | |