... | ... | @@ -67,12 +67,14 @@ This is an array og objects each describing a tab in the workflow, with attribut |
|
|
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. 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.
|
|
|
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. This is to distinguish this kind of input from inputs used for predefined values (see below), where the value also is an uri.
|
|
|
|
|
|
Another important input type is dropdown list with predefined values, such as language. The actual values are extracted from the ontology.
|
|
|
When searching, a popup list with search results appears next to the field, where one can select one of existing resources, or create a new one. The input which is searchable will refer to one or more elasticsearch index types via its `indexTypes` property. If more than one index type is searchable as a source, a select box will appear. This is used when e.g. searching for candidates for subjects for works, which may link to different types of authorities, such as _Subject_, _Person_ and even other _Work_.
|
|
|
|
|
|
Some inputs allow multiple values, others don't.
|
|
|
From the referred search specification, the property `resultItemLabelProperties` lists which properties from the resulting search documents are to be used as source for search results labels. On the other hand, when the value of an already entered link to another resource is to be shown, the input 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 for both search result and triple store labels are `prefLabel`, `name` etc, depending on the search index document structure.
|
|
|
|
|
|
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 don't. Since some inputs allow multiple value from the sets of predefined values, it is handy to realize these as html select elements. Due to the way two-way binding works in Ractive for these kinds of input controls, this is modeled as an array of values, rather than as an array og objects with `current.value` properties as is the case for other types of input. Some of the complexity when it comes to filling up values in the input structure is related to this difference.
|
|
|
|
|
|
An important property of inputs are `widgetOptions` structure 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 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`.
|
... | ... | @@ -92,11 +94,24 @@ The state of the application is held in a set of object structures under the con |
|
|
### Partials
|
|
|
Even if the application's main engine is a massive block of code, the user interface is divided into a number of parts, called partials in Ractive.js lingo. Partials feed on the context in which they are invoked, such as an `input` node as the example above.
|
|
|
|
|
|
### Decorators
|
|
|
|
|
|
# Development
|
|
|
# Development tips
|
|
|
## Inspecting state
|
|
|
To inspect the state of the model, execute `document.main.getRactive().get(<keypath>)`from the development console in e.g. Chrome. Empty argument returns the ractive top level, where one can drill down to specific points of interest.
|
|
|
## Print keypath in user interface
|
|
|
When one is in doubt if keypaths in the html files are correct, insert `{{@keypath}}` to print out the path to where in the structure your markup is working.
|
|
|
## Observe changes
|
|
|
Sometimes it can be hard to see where a value in the structure has been changed from. By adding a intermittent observer, one can catch where changes originate from. Execute a statement like this in the console:
|
|
|
|
|
|
`document.main.getRactive().observe('inpuGroups.3.inputs.4.values.2.current.value', function(newVal, oldVal, keypath){debugger;},{init:false})`
|
|
|
|
|
|
Do whatever ui interaction that triggers an unexpected change, and when the debugger stops, examine the stack, looking especially for lines within `main.js`.
|
|
|
|
|
|
## Random external data
|
|
|
To test and develop handling of external data, the backend can serve random suggestions for new data. To achieve this, start Catalinker with additional url parameters like these: `externalSource=random_bibbi`. Entering any ISBN will populate suggested data with nonsensical work, publication and person data. Adding `externalSource=random_loc` as url parameter also fetches data as from a secondary source.
|
|
|
|
|
|
# Testing
|
|
|
## Module tests
|
|
|
There is a simple module test that tests whether the workflow can be instantiated, but is has not been augmented for a long time.
|
|
|
|
|
|
## Cucumber tests
|
|
|
Each new feature added has been accompanied by new or by extending the existing feature tests. The tests generally walk through the cataloguing workflow creating new authorities, and link them together. The old parts of the interface is used to check values after test scenarios, but is limited when it comes to showing e.g. compound inputs. |