... | ... | @@ -28,7 +28,20 @@ The use interface is constructed with thee help of one from of a handful of _tem |
|
|
### Ractive.js
|
|
|
Catalinker uses Ractive.js web framework, developed by the Guardian newspaper. Its main purpose is two-way binding between input fields and javascript object structures, suitable for rendering a complex user interface backed by an application state.
|
|
|
### main.js
|
|
|
Most of the functionality in Catalinker is in main.js. main.has grown from its simpler state in the old catalinker mentioned earlier to a quite large chunk of javascript code. Some parts and functions are more complex than others, and cater for more than one concern. No doubt should the file be divided into smaller modules and perhaps utilise ractives component support, but because of the incremental nature of the development process followed, and perhaps lazinesss, it has not come to this yet. However, most functions are kept small and with descriptive names, and the structure is the same as from the beginning, only with more features added.
|
|
|
Most of the functionality in Catalinker is in main.js. main.has grown from its simpler state in the old catalinker mentioned earlier to a quite large chunk of javascript code. Some parts and functions are more complex than others, and cater for more than one concern. No doubt should the file be divided into smaller modules and perhaps utilise ractives component support, but because of the incremental nature of the development process followed, and perhaps laziness, it has not come to this yet. However, most functions are kept small and with descriptive names, and the structure is roughly the same as from the beginning, only with more features added.
|
|
|
|
|
|
The outline of `main.js`is as follows:
|
|
|
* Require directives, e.g. requiring jquery and jquery-ui artifacts.
|
|
|
* Various functions
|
|
|
* Dialog handlers using jquery-dialog
|
|
|
* Functions handling input values. Most important is `updateInputsForResource` which does all the heavy lifting when it comes to filling data into inputs from saved resources, external data as suggestions, resources to be compared with and paging of multi-valued compound input values.
|
|
|
* Functions for converting configuration and ontology into input structure
|
|
|
* Functions for handling patching and saving of new data
|
|
|
* Ractive decorators. These are used to handle different ui requirements, such as select2 style select components, sliding elements, accordion, input field ornamentation, special formatting, maintaining support panel positioning
|
|
|
* The ractive instance, with
|
|
|
** Event handlers
|
|
|
|
|
|
|
|
|
### workflow_config.js
|
|
|
The configuration file mainly consists of these groups:
|
|
|
* inputForms
|
... | ... | @@ -56,13 +69,16 @@ 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 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.
|
|
|
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 the elasticsearch search routes for each resource type along with which indexed document's fields to query for and which fields to show in result list.
|
|
|
|
|
|
#### `prefillValuesFromExternalSources`
|
|
|
Configures how suggestion data from external sources are mapped into inputs. Catalinker receives data from external sources through services in RDF-format, some of which may be turned into new authorities such as _Person_ or _Subject_.
|
|
|
|
|
|
### State model
|
|
|
The state of the application is held in a set of object structures under the control of the Ractive.js instance. The most important part of the structure is the `inputGroups`, which is derived from the `tabs` array in the configuration. Accessing the model is done via `ractive.get()` function with a path as argument, e.g. `ractive.get('inputGroups.1.inputs.3')` which retrieves the fourth input of the second tab. Each input again has a `values` array, each having a `current.value` and `old.value`. When values are changed, a patch is generated based on difference between a value's old and current value. The patch is then sent to back end as a `HTTP PATCH`.request Values representing a link to another resource has in addition a `displayValue` field, showing the name or a more user friendly representation of the linked resource.
|
|
|
The state of the application is held in a set of object structures under the control of the Ractive.js instance. The most important part of the structure is the `inputGroups`, which is derived from the `tabs` array in the configuration anriched by ontology. Accessing the model is done via `ractive.get()` function with a path as argument, e.g. `ractive.get('inputGroups.1.inputs.3')` which retrieves the fourth input of the second tab. Each input again has a `values` array with each element having a `current.value` and `old.value`. When values are changed, a delta is generated based on difference between a value's old and current value. The delta is then sent to back end as a `HTTP PATCH`-request. Value structs representing a link to another resource has in addition a `displayValue` field, containing the name or a more user friendly representation of the linked resource.
|
|
|
|
|
|
### 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.
|
... | ... | |