... | ... | @@ -17,17 +17,24 @@ The node back end enforces aggressive caching, to minimize loading time. |
|
|
### Proxying service calls
|
|
|
All actual data processing; POST, PATCH etc are forwarded to the services container. GETs are cached, but invalidated by POSTsand PATCHes to same resources.
|
|
|
## Application structure
|
|
|
To allow flexibility with respect to ontology and workflow supported, the application conceptually consists of a front end that knows how to render any number of input fields grouped by tabs and connected to specific RDF targets such that each tab roughly concerns some aspects of one resource. A resource in this cace can be a Work og a Publication. These corresponds to resource types from the ontology. Each tab also has a button to navigate to the next tab, supporting a particular work flow e.g. search for a work, then create a publication of it and then link it to the work. In addition, tabs may be selected explicitly once enabled by the workflow state. The application is deigned to be capable of handling a somewhat shallow hierarchy of objects, more specifically Works as top nodes and one or more Publications as children. Depending on context, the editor at any time targets a Publication and its Work or only a Work instance. In the former case, the uri of the Publication infers also the uri of the work, so only the uri of the Publication is present in the address bar.
|
|
|
To allow flexibility with respect to ontology and workflow supported, the application conceptually consists of a front end that knows how to render any number of input fields grouped by tabs and connected to specific RDF targets such that each tab roughly concerns some aspects of one resource. A resource in this case can be a _Work_ og a _Publication_. These corresponds to resource types from the ontology. Each tab also has a button to navigate to the next tab, supporting a particular work flow e.g. search for a work, then create a publication of it and then link it to the work. In addition, tabs may be selected explicitly once enabled by the workflow state. The application is deigned to be capable of handling a somewhat shallow hierarchy of resources, more specifically _Work_s as top nodes and one or more _Publication_s as children. Depending on context, the editor at any time targets a _Publication_ and its parent _Work_ or only a _Work_ instance. In the former case, the uri of the _Publication_ infers also the uri of the _Work_, so only the uri of the _Publication_ is present in the address bar.
|
|
|
|
|
|
A guiding principle during development has been to separate the general from the specific, so that the front end in principle should be able to handle any type of resource in a structure, not only Works and Publications, but e.g. Buildings and Floors. "Publication" and "Work" are therefore mentioned as rare as possible, but it has not been totally avoided. One could argue that the mindset has been kept, however. To support the principle above, all specific behavior is configured in the file `workflow_config.json`, which is served by the back end. The configuration file describes which predicate from the ontology goes to which tab in the workflow, and other helper functions like how to search for relevant values when linking to authorities, which fields should be shown when creating new authorities etc.
|
|
|
A guiding principle during development has been to separate the general from the specific, so that the front end in principle should be able to handle any type of resource in a structure, not only _Work_s and _Publication_s, but e.g. Buildings and Floors. "Publication" and "Work" are therefore mentioned as rare as possible in the code, but it has not been totally avoided. One could argue that the mindset has been kept, however. To support the principle above, all specific behavior is configured in the file `workflow_config.json`, which is served by the back end. The configuration file describes which predicate from the ontology goes to which tab in the workflow, and other helper functions like how to search for relevant values when linking to authorities, which fields should be shown when creating new authorities etc.
|
|
|
|
|
|
Following the from above, all solutions are designed to be as generic as possible, even if used only once.
|
|
|
Following the from above, all solutions are designed to be as generic as possible, even if used only once. The separation of code and configuration means that it should be fairly easy to adapt to another workflow or ontology, simply by replacing the configuration file or parameterize it, supporting other needs.
|
|
|
|
|
|
### 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.
|
|
|
### workflow_config.js
|
|
|
The configuration file mainly consists of these groups:
|
|
|
* inputForms
|
|
|
* tabs
|
|
|
* authorityMainintenance
|
|
|
* search
|
|
|
* prefillValuesFromExternalSources
|
|
|
|
|
|
### State model
|
|
|
### Partials
|
|
|
### Decorators
|
... | ... | |