... | ... | @@ -37,14 +37,21 @@ The configuration file mainly consists of these groups: |
|
|
|
|
|
#### `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.
|
|
|
### `tabs`
|
|
|
#### `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.
|
|
|
|
|
|
Another important input type is dropdown list with predefined values, such as language. The actual values are extracted from the ontology.
|
|
|
|
|
|
Some inputs allow multiple values, others not.
|
|
|
|
|
|
An important property of inputs are `widgetOptions` which holds various configurations for an input, such as which form (from `inputForms` above) to show when opening a related authority for in situ editing - if the input field is of a type than links to another resource. `widgetOptions` is also used for other specialized control of input fields.
|
|
|
|
|
|
Some inputs are nested, and therefore has both their own predicate 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_.
|
|
|
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`.
|
|
|
### State model
|
|
|
### Partials
|
|
|
### Decorators
|
... | ... | |